Creation and modification dates not preserved on sync


ogrfnkl

Recommended Posts

When syncing from a Windows 10 PC to any Android device (I've tried it with both a Galaxy S4 phone and a Galaxy Note 10.1 2014 Edition, running on anything from Kitkat to Marshmallow), both the creation and the modification dates/times of destination files are set to the time of the sync. Thus, on the destination device, they immediately become newer than on source. This happens when syncing onto either the internal or the external SD card. Please help!

Link to comment
Share on other sites

@ogrfnkl For the file creation time - it is not something we adjust.

For the mtime - this is Android distro limitation. Sync adjusts mtime after delivering files (but not folders) on all platforms, although on many Android distros the OS itself reports successful mtime adjustment, while actually keep old mtime. To track things correctly, Sync has to store real mtime of a file in its DB.

Link to comment
Share on other sites

Hello, RomanZ, thanks for your reply. I am not sure, though, what you mean by the OS keeping the OLD mtime... The whole problem here is that after syncing, the files all end up having the timestamp from the time of the sync, and it is this NEW mtime that sticks around. Perhaps what you meant to say is that BT Sync attempts to set mtime to the OLD value (that of the SOURCE file), but the OS keeps the new mtime -- is that correct? If so, I suspect that Android does that simply because it won't tolerate mtime to be set to a lesser value than the creation time.

Question: why can't BT Sync simply try to set both creation AND mtime on the target file to their source values? Isn't that the whole point of syncing files between devices in the first place -- making an exact copy of each file, and then propagating any changes based on the mtime value?

Edited by ogrfnkl
Link to comment
Share on other sites

Just to add -- exactly the same problem has occurred on stock Samsung Kitkat (on the Galaxy Note 10.1 2014 Edition) and on Cyanogenmod Lollipop and later Marshmallow (on the Samsung Galaxy S4). Which Android distros DO support the proper setting of mtime, then? I suspect that it has more to do with the fact that the creation date/time is not being set properly, and hence mtime fails, too. Does that sound correct to you?

Link to comment
Share on other sites

Quote

Perhaps what you meant to say is that BT Sync attempts to set mtime to the OLD value (that of the SOURCE file), but the OS keeps the new mtime -- is that correct?

Exactly. Your explanation is much more elegant :)

Quote

Question: why can't BT Sync simply try to set both creation AND mtime on the target file to their source values? Isn't that the whole point of syncing files between devices in the first place -- making an exact copy of each file, and then propagating any changes based on the mtime value?

Devs did a whole research on the topic. Some distros were okay to set mtime, some not, some required additional actions like setting creation time. At the end of day we came to conclusion that it is more effective to store real mtime in our DB rather than craft Sync for every distro.

Quote

Which Android distros DO support the proper setting of mtime, then? I suspect that it has more to do with the fact that the creation date/time is not being set properly, and hence mtime fails, too. Does that sound correct to you?

Sorry, we don't have this information anymore. It was really long time ago. Once we've found a solution, we no longer keep track of such differences.

 

 

Link to comment
Share on other sites

So, if I understand you correctly, even though the mdates on the mobile device end up being incorrect, Sync keeps track of the correct date for each file in its internal database and when a file changes (and thus gets a newer mtime), detects that and syncs it back to the PC, is that right?

If that is the case, I'd like to tell you that about a year ago, I tried to use BT Sync bidirectionally, and even though in the beginning everything seemed to work fine, shortly afterwards, I noticed that it was massively overwriting my files on the PC with ones from the phone, which haven't really changed, but have the later mtime because of the Sync. That indicates that sometimes this database scheme fails, and Sync begins to take those incorrect mdates at face value. I also lost some files on the PC that were newer versions, but were still overwritted by the older version from the mobile device. Fortunately, I have good backup habits, so I didn't lose a lot of data, but still, with pain in my heart, I had to stop using the very useful bidirection Sync capability. I really, really hope all this will get sorted out some time soon, as Sync's functionality is EXACTLY the solution I need for my situation...

I also realize that the biggest culprit here is Google, as it is totally inexcusable that after 7 years on the market, Android still can't handle something as simple and fundamental as setting a file's modification date.

Cheers,
Oleg.

Link to comment
Share on other sites

  • 3 weeks later...

Oleg,

You understand correctly. When syncing data from Android to other platforms, Sync let know the real mtime of a file, not the one assigned by Android. The only exception is when file gets modified on Android - in this case, the mtime assigned by OS becomes true.

Quote

If that is the case, I'd like to tell you that about a year ago, I tried to use BT Sync bidirectionally, and even though in the beginning everything seemed to work fine, shortly afterwards, I noticed that it was massively overwriting my files on the PC with ones from the phone, which haven't really changed, but have the later mtime because of the Sync. That indicates that sometimes this database scheme fails, and Sync begins to take those incorrect mdates at face value. I also lost some files on the PC that were newer versions, but were still overwritted by the older version from the mobile device. Fortunately, I have good backup habits, so I didn't lose a lot of data, but still, with pain in my heart, I had to stop using the very useful bidirection Sync capability. I really, really hope all this will get sorted out some time soon, as Sync's functionality is EXACTLY the solution I need for my situation...

Shouldn't be the problem since 2.2 release for sure (maybe even earlier).

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.