Android MTP sync with Windows

For technical support visit http://support.2brightsparks.com/
jeffshead
Newbie
Newbie
Posts: 5
Joined: Thu May 30, 2013 4:48 pm

Android MTP sync with Windows

Postby jeffshead » Tue Nov 14, 2017 1:49 pm

According this forum post (viewtopic.php?f=15&t=12408&p=47461&hilit=mtp#p47461), there is currently no way to sync data between Windows and and external SD card on an Android.

Is there anyway to at least be able to mirror a Windows folder to the Android which copies and deletes only changed files?

cliffhanger
Expert
Expert
Posts: 753
Joined: Tue May 31, 2011 5:59 pm

Re: Android MTP sync with Windows

Postby cliffhanger » Tue Nov 14, 2017 3:25 pm

Have you tried following the breadcrumb trail in this thread back to Topic 12129 and using the Fast Backup option mentioned by Kostas? This should work as a Mirror (of Windows folder/s to SD card) provided you (or your phone, etc,) do not unilaterally change anything on the SD card. If you ensure that only the [Mirror profile using Fast Backup] effects any changes on the SD card, the [profile I just mentioned] should be able to keep track of what the SD card's files' metadata should have been if SB was allowed to update it.

I recommend using SB Touch rather than MTP unless you are absolutely sure the only files you want to Mirror are 'media files' (as defined by Windows and/or your phone's firmware). MTP is a little flaky (also other restrictions, such as does not support Verify). Your other thread in 2016 suggests you are aware of Touch, also of the niceties of enabling Touch to use the ext SD

jeffshead
Newbie
Newbie
Posts: 5
Joined: Thu May 30, 2013 4:48 pm

Re: Android MTP sync with Windows

Postby jeffshead » Tue Nov 14, 2017 8:21 pm

cliffhanger wrote:...Fast Backup option mentioned by Kostas?...

I will take a closer look at Fast Backup. I tried to enable it before I created this thread but I got the, "Fast Backup is not available because this is a sync profile" warning.
cliffhanger wrote:I recommend using SB Touch rather than MTP...

I tried SB Touch but it was incredibly slow compared to MTP via USB. I also encountered the same issue with both connections -- Instead of coping and deleting only changed files (2-way), I was prompted to copy almost all files from the Android to the Windows PC.

Can you explain the benefit of using the MTP option depicted below:
Image

cliffhanger
Expert
Expert
Posts: 753
Joined: Tue May 31, 2011 5:59 pm

Re: Android MTP sync with Windows

Postby cliffhanger » Wed Nov 15, 2017 10:32 am

jeffshead wrote:
cliffhanger wrote:...Fast Backup option mentioned by Kostas?...

I will take a closer look at Fast Backup. I tried to enable it before I created this thread but I got the, "Fast Backup is not available because this is a sync profile" warning

Yes, you will get that warning in a sync profile. If, however, you set up (start with) a Mirror, which is what you asked about ("...mirror a Windows folder to the Android"), you can use Fast Backup with such a Mirror profile. Note that the first run with the profile configured to use Fast Backup will want to copy everything again, because it has no database yet of the SD card files' state (it's about to create one). Scanning should be faster on run-2 (etc) as a Fast Backup, and, while actual copy speed (per MB, etc.) won't change, overall copy duration should improve once the Mirror with Fast Backup has something else (its previous-state database) to rely on (to tell which files need copying - and, more importantly, which do not) apart from the false meta-data on the SD card that SB was forced to leave behind previously.

jeffshead wrote:Can you explain the benefit of using the MTP option depicted below:
Image

Another way around the date/time-mismatch problem is (immediately after copying any given file) to set/change the Source (in your case, PC side) file's LastModified stamp to match the new/false/ostensible-LastModified stamp on the Destination (SD card) file (ditto for each file the profile copies). This should in theory (if you can rely on MTP to be consistent/accurate when writing/reading-back metadata, which is not always the case) mean the files should, at the end of the profile run, match on each side (albeit by using 'fictional' LastModified stamps on each side).

However, you have just lost any true record in the Source folder of when those files were truly LastModified (and, of course, you never had a true LastModified record on the SD side). Whether that is important to you or not I have no idea, but many people are uncomfortable with the concept of throwing away accurate metadata to achieve a match with false metadata. For example, if you rely on comparing true LastModified stamps to create/update a subset of MP3s in that Windows folder (maybe from a much larger set stored elsewhere) to copy to the SD card. throwing away the true LastModified stamps of the subset files stored in the Windows folder may break the subset-update process, the sort order by (true) LastModified, and so on. One possibility is that your subset-update process may re-copy everything to the (Windows) subset again* (because subset metadata now doesn't match the main-store metadata any more), and if it does, your Windows subset now doesn't match the files on the SD card any more #-o


* it is also possible any subset-update process (if it is a 2-way sync) may want to copy the subset-copy files to the main-store instead (overwriting main-store copies) because the subset copies now 'look' newer.

jeffshead
Newbie
Newbie
Posts: 5
Joined: Thu May 30, 2013 4:48 pm

Re: Android MTP sync with Windows

Postby jeffshead » Wed Nov 15, 2017 5:18 pm

Wow! Thanks for all of the info.

I did try the MTP setting that changes the Source LastModified stamp to match the new/false/ostensible-LastModified stamp on the Destination (SD card). It worked for syncs I did yesterday. However, today (even though no files were modified on the SD card nor the PC, SyncBack prompted me to copy all files to the PC.

I would rather 2-way sync but it doesn't look like it is possible (am I wrong) so that's why I asked about doing a mirror. I'll try the mirror and see how it does.

jeffshead
Newbie
Newbie
Posts: 5
Joined: Thu May 30, 2013 4:48 pm

Re: Android MTP sync with Windows

Postby jeffshead » Wed Nov 15, 2017 8:21 pm

Just tried the mirror with Fast Backup. It does not delete files on the SD card that are not on the source. Doesn't even show there is a difference between the source and destination :(

cliffhanger
Expert
Expert
Posts: 753
Joined: Tue May 31, 2011 5:59 pm

Re: Android MTP sync with Windows

Postby cliffhanger » Thu Nov 16, 2017 11:33 am

Works for me (I just tried it). If I perform an initial run of the profile (to build the FB database) then manually delete (from Source) a file already present on both sides, the profile proposes to delete the copy on the phone. It also works if I rename a file on the Source (it deletes 'old name' on phone and copies 'new name' to the phone. Both tests perform exactly as I would expect them to.

But, I notice you say "Doesn't even show there is a difference between the source and destination" - are you by any chance using 'Perform a fast backup using the archive attribute''? That won't work for a Mirror (except on a Rescan) as explained in the Help (albeit in two different places) as follows.

The Help on Fast Backup itself (F1 on Fast Backup settings page) has a clause which states:

If the profile is set to delete destination-only files, SyncBack may not know a new file has been created in the destination (see this section for more details). (By logical extension, the converse may also apply, i.e. if a file is deleted from Source but a copy is left on the Destination.)

The 'this section' phrase is a link (in the Help - it won't work here!) to the Decisions-Files settings page, which has a section at the bottom (my underlining) called

Fast Backup

If you are using Fast Backup then you must keep in mind that SyncBack does not scan the destination unless it is a rescan. For example, if you are using a Fast Backup profile that uses the archive attribute, and it is not a rescan, and you've configured the profile to delete destination-only files, then it does not know what files are in the destination. This means if you create a new file in the destination, or delete a file from the source, then it will do nothing. If you are using a fast backup that does not use the archive attribute, and it is not a rescan, and you've configured the profile to delete destination only files, then it works slightly differently than the archive attribute method. This is because SyncBack keeps track of what files were previously in the source (which should therefore be the same as the destination). If you delete a file from the source, and there is an equivalent destination file, then it will delete the destination file. However, if you create a new file in the destination then it will not be deleted.


TL:DR - using an archive-bit-based Fast Backup (on a non-initial/non-rescan run) relies 100% on the state of the present Source files. It doesn't reference either the Destination files or a database that records previous-state. There are also no gravestones on the Source to say 'a file was here and now it isn't'. The profile thus has no way of knowing (and receives no hints) by reading the Source alone that a copy of the deleted file exists on the Destination (except by scanning there and believing the info stored there, which is expressly what you are trying to avoid, so it doesn't).

So, if you are using archive-bit Fast Backup, you need to change to the FB method that uses a database (to 'keep track' as mentioned in previous Help quote). You need to select the radio button that simply says 'Perform a fast backup'. You will need to run it again to generate the database, then try your test again (delete something from Source / run again) and you should see the profile propose to delete the corresponding file on Destination. I certainly do.


Return to “SyncBackPro (commercial)”



Who is online

Users browsing this forum: No registered users and 3 guests