Modified date on android devices: Possible solution?

Discuss new features and functions
Posts: 7
Joined: 11 Dec 2018

HiPerFreak

Helle everybody,

thank you very much for this great piece of software!

When syncing files with my Android 6 HTC device, I get the error message "SetValues failed for WPD_OBJECT_DATE_MODIFIED (0x80070005, Access is denied)", and of course when I check the modification date it is set to the current date time.

BUT: When I copy the same file with the windows explorer, the modification date of the new file is correctly set to the original date! So obviously there seems to exist a way/an API to correctly set the modification date at least for new files (updating could be workarounded by deleting and recreating).

So I really wonder if you have investigated this way of doing it...

For me, the modification date is essential, because the HTC photo gallery app orders my pictures by modification date (and this cannot be changed), and when I do a sync, the sequence of the pictures is completely messed up... :(

I would really love to hear your opinion on this point!!!

Best regards,
Daniel
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

Here's a link to an old FreeFileSync version that uses a strategy probably similar to what Explorer is doing (= it sets modTime right during file creation instead of afterwards). Does this correctly set modification times on your Android?
https://www.mediafire.com/file/3iavwthq3je7gao/FreeFileSync_8.10_Windows_Setup.exe
Posts: 7
Joined: 11 Dec 2018

HiPerFreak

Hi Zenju, thank you very much for your answer!! Yes, this version does set the modification date correctly when "adding a new file" and when "updating a file" on the android device (just tested with a single file).

I would really love to see an option to choose the copy method in the "Synchronization Settings" dialog!
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

Here's the final implementation that will be in the next release. Please let me know if there are any issues. I've changed the behavior when setting modification time to do so already during file creation. This will solve the issues with your Android version 6 (I couldn't reproduce it with the newer Android 8.1, but your version is still quite widespread).
https://www.mediafire.com/file/tn0en5oybtaoay9/FreeFileSync_10.8_%5BBeta%5D_Windows_Setup.exe/file
Posts: 2
Joined: 30 Dec 2018

iBeta

Had the same problem, the 10.8 beta version appeared to fix it - the android files showed the correct timestamps in windows explorer. However looking directly at the files via the phone, the timestamps were reset.
Samsung Galaxy S9+ (Android 8) <-> Windows 7 x64.
Edit - Also tried with v8.10. Again all device files are timestamped with current time.
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

@iBeta: Thanks for your testing! It seems the new version has also "solved" a different issue of time stamps not being preserved. Still a bit surprising that there is a difference in this regard between the old FFS 8.10 and the 10.8 beta.
Posts: 3
Joined: 1 Jan 2019

mehcoj

Hi and happy new year,
I have now the same issue when sync about 100GB using a windows 10 notebook on a Synology DiskStation (linux based) to an remoted attached USB Drive (to the DiskStation). The modified time was set to the creation time or during the next run to the current time. Not all files are handled in that way but I can not find a rule. Running the sync again some more files are correct, but most of the files are wrong. I using the new beta 10.8 after found this post.

Any ideas?

regards, Mehcoj
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

Hi and happy new year,
I have now the same issue when sync about 100GB using a windows 10 notebook on a Synology DiskStation (linux based) to an remoted attached USB Drive (to the DiskStation). The modified time was set to the creation time or during the next run to the current time. Not all files are handled in that way but I can not find a rule. Running the sync again some more files are correct, but most of the files are wrong. I using the new beta 10.8 after found this post.

Any ideas?

regards, Mehcoj mehcoj, 01 Jan 2019, 12:56
This is unrelated to the MTP issue discussed above. For your problem, see: https://freefilesync.org/faq.php#different-after-sync
Posts: 3
Joined: 1 Jan 2019

mehcoj

@zenju:

thx for clarification and for the quick response...

But still have the issue and can not find a process running on the synology diskstation that change the datetime stamp back. Using the sync over the networking from the notebook to the diskstation everything works fine. But syncing foreword to the attached usb drive from the diskstation causes that problem.

When I use the windows explorer and copy the files manually from the diskstation to the attached usb drive that modification datetime stay unmodified.

Regards, mehcoj
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

But still have the issue and can not find a process running on the synology diskstation that change the datetime mehcoj, 01 Jan 2019, 13:55
Probably not on the diskstation, but on your local PC. If you send me a Process Monitor trace I can have a look.
Posts: 3
Joined: 1 Jan 2019

mehcoj

many many thanks for your support and sorry for my bad English. I’m from Germany. I send the file per mail.
Posts: 7
Joined: 11 Dec 2018

HiPerFreak

Here's the final implementation that will be in the next release. Please let me know if there are any issues. I've changed the behavior when setting modification time to do so already during file creation. This will solve the issues with your Android version 6 (I couldn't reproduce it with the newer Android 8.1, but your version is still quite widespread).
https://www.mediafire.com/file/tn0en5oybtaoay9/FreeFileSync_10.8_%5BBeta%5D_Windows_Setup.exe/file Zenju, 29 Dec 2018, 14:28
Hi Zenju,

thank you very much for your efforts. I tried this version with my Android 6 just now, and I am still getting the warning "Setting the modification time silently ignored by the device.", but it nevertheless correctly sets the modification date (same with "Fail-safe file copy" checked or unchecked).

On my Android 8 from Huawei, I couldn't find any way to transfer a modification date. Even with Explorer it doesn't work... :(

Best regards,
Daniel
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

I tried this version with my Android 6 just now, and I am still getting the warning "Setting the modification time silently ignored by the device.", but it nevertheless correctly sets the modification date HiPerFreak, 01 Jan 2019, 19:41
MTP is such a mess, but we're still making progress. Since MTP silently ignores errors to set the modification time, FFS does an explicit check if it worked, and this checked failed for inconceivable reasons when, as you report, the mod time is in fact correct when you check manually. I'm not sure what to make of this, maybe just another MTP quirk. Anyway, the error message above isn't great, so I've added the actual modification times involved, which could give some further insights: https://www.mediafire.com/file/oss91x06ec3rfcf/FreeFileSync_10.8_%5BBeta%5D_Windows_Setup.exe
Posts: 7
Joined: 11 Dec 2018

HiPerFreak

Hi Zenju,

the problem seems to be that the explicit check does not consider the "Ignore time shift" setting (set to 1 and 2 in my case). The detailed error message was "Setting the modification time (13.11.2018 11:08:50) was silently ignored by the device (13.11.2018 10:08:50)."

Thank you for your efforts and the very fast response.
Posts: 21
Joined: 5 Oct 2018

jmsxl

I just want to say Thank You for continuing to work around the poorly implemented MTP. FFS's support of MTP is really good, in the face of such a botched protocol extension.
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

the problem seems to be that the explicit check does not consider the "Ignore time shift" setting (set to 1 and 2 in my case). The detailed error message was "Setting the modification time (13.11.2018 11:08:50) was silently ignored by the device (13.11.2018 10:08:50)." HiPerFreak, 01 Jan 2019, 20:40
So when you say "it nevertheless correctly sets the modification date" you actually mean "with an 1 hour offset"!? Or is this offset only shown in the warning message above, but not detectable when you compare file times (with FreeFileSync) after the sync?
Posts: 7
Joined: 11 Dec 2018

HiPerFreak

Sorry for being unclear, I mean it is set with an 1 hour offest (as expected due to MTP and file system...).
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

Sorry for being unclear, I mean it is set with an 1 hour offest (as expected due to MTP and file system...). HiPerFreak, 03 Jan 2019, 11:36
Is this offset also visible in FreeFileSync's "date" columns after sync and comparing again?
Posts: 7
Joined: 11 Dec 2018

HiPerFreak

Yes it is, I have attached a screenshot (left side computer, right side android):
ffs_screenshot.jpg
ffs_screenshot.jpg (27.2 KiB) Viewed 14343 times
If I enter 1,2 into the "ignore time shift" filed, comparison shows no changes to sync.
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

Yes it is, I have attached a screenshot (left side computer, right side android):
ffs_screenshot.jpg HiPerFreak, 03 Jan 2019, 14:00
Thanks for the clarification, so at least FFS's explicit check after sync is working as expected. The fact that Android 6 changes the input time by some offset is a quirk that I cannot reproduce on Android 8.1. But then again, Android 8.1 seems to "forget" any modification times when the USB cable is disconnected and reconnected again, which is an even bigger screw up. Still, it seems FFS 10.8's behavior regarding MTP is now probably as good as it can get considering MTP's limitations.
Posts: 2
Joined: 30 Dec 2018

iBeta

For me, the time is immediately reset to current on the Android 8 device files. The pc has no firewall, and Windows Indexing is disabled.
Are you saying it is not possible to prevent the time modification on the device files, due to MTP. If so, will it not be fixed in Android 9?
Posts: 7
Joined: 11 Dec 2018

HiPerFreak

Thanks for the clarification, so at least FFS's explicit check after sync is working as expected. The fact that Android 6 changes the input time by some offset is a quirk that I cannot reproduce on Android 8.1. But then again, Android 8.1 seems to "forget" any modification times when the USB cable is disconnected and reconnected again, which is an even bigger screw up. Still, it seems FFS 10.8's behavior regarding MTP is now probably as good as it can get considering MTP's limitations. Zenju, 03 Jan 2019, 20:52
In my opinion it would be more consistent, if the date check after copying behaves the same way as the check when doing the "Compare" operation. This means that if I have set the "Ingore time shift" field to "1,2" the warning should not appear if the dates differ only by exactly one or two hours. That's what this setting is for after all, right (i.e. a workaround for the problem with different time zones, as far as I could defer from the documentation)?
User avatar
Site Admin
Posts: 7040
Joined: 9 Dec 2007

Zenju

Are you saying it is not possible to prevent the time modification on the device files, due to MTP.
If so, will it not be fixed in Android 9? iBeta, 03 Jan 2019, 22:41
If Google really wanted, they'd have fixed this age-old "bug" regarding not accepting modification times long ago.

In my opinion it would be more consistent, if the date check after copying behaves the same way as the check when doing the "Compare" operation. This means that if I have set the "Ingore time shift" field to "1,2" the warning should not appear if the dates differ only by exactly one or two hours. That's what this setting is for after all, right (i.e. a workaround for the problem with different time zones, as far as I could defer from the documentation)? HiPerFreak, 04 Jan 2019, 00:47
MTP returning a different time than what was set only milliseconds before is simply yet another "bug" and has nothing to do with time zones or daylight saving time. OTOH there's nothing the user can do about it, so it would be nice if this particular warning was ignored when "Ignore time shift" is set. However it seems simply permanently ignoring the warning is a good enough solution.