Error Code 87: the SetFileTime parameter is incorrect

Get help for specific problems
Catalyst
Posts: 1
Joined: 12 Feb 2016

Post by Catalyst • 12 Feb 2016, 01:18

I have only used FFS twice and both times I am stopped with this error on numerous files, when Mirroring files from Windows 7 to USB Flash drive.

"Cannot write modification time of W7 Install Log.doc.ffs_tmp". A FAT volume can only store dates between 1980 and 2107, but files dates are within this range.

I never had this problem with other sync apps including Allways Sync.

How can I correct this issue?

Thank you!
Error Code 87.png
Error Code 87.png (6.94 KiB) Viewed 3770 times
File Dates.png
File Dates.png (8.44 KiB) Viewed 3770 times

User avatar
Zenju
Site Admin
Posts: 4696
Joined: 9 Dec 2007

Post by Zenju • 12 Feb 2016, 16:15

The problem is not the creation time of the file on "Z:\" but of the one on the source side. Anyway, FFS should not fail for a broken creation time, so I'll see to make the copy routine more tolerant.

User avatar
Zenju
Site Admin
Posts: 4696
Joined: 9 Dec 2007

Post by Zenju • 17 Feb 2016, 12:43

The issue has been fixed! Let me know in case of any other issues:
http://www.mediafire.com/download/vubnvxuvgw25cup/FreeFileSync_7.10_beta_Windows_Setup.exe

Gpx
Posts: 9
Joined: 3 Mar 2016

Post by Gpx • 03 Mar 2016, 13:27

Zenju

I have tried beta 10 and I still have the same issue.

I am trying to copy to a FAT network drive some files that are stored on my PC (NTFS). All dates of the original files are 2016 (created, modified, last accessed), so within the FAT time stamp range I believe. I am not updating files on my network drive I am trying to create brand new files.

Many thanks

Greg

User avatar
Zenju
Site Admin
Posts: 4696
Joined: 9 Dec 2007

Post by Zenju • 03 Mar 2016, 15:22

Gpx wrote: I have tried beta 10 and I still have the same issue.
What error message are you getting?

Gpx
Posts: 9
Joined: 3 Mar 2016

Post by Gpx • 03 Mar 2016, 19:01

The same as above, but only for Write (UTC), not for Created (UTC)

Thanks Zenju

User avatar
Zenju
Site Admin
Posts: 4696
Joined: 9 Dec 2007

Post by Zenju • 03 Mar 2016, 19:02

Then it's a legitimate error unless Windows Explorer shows a different modification time for this file.

Gpx
Posts: 9
Joined: 3 Mar 2016

Post by Gpx • 03 Mar 2016, 19:08

All dates (created , write, accessed) for this file are 2016. I do not understand

User avatar
Zenju
Site Admin
Posts: 4696
Joined: 9 Dec 2007

Post by Zenju • 03 Mar 2016, 21:03

Can you post a few screenshots comparing what is shown in FFS with Explorer?

Gpx
Posts: 9
Joined: 3 Mar 2016

Post by Gpx • 04 Mar 2016, 22:33

Zenju

Here are the screenshots. Quite self explanatory but it's in French though so tell me if you need translation.

Thanks
Attachments
Capture1.png
Capture1.png (12.99 KiB) Viewed 3554 times
Capture2.png
Capture2.png (14.72 KiB) Viewed 3554 times

Gpx
Posts: 9
Joined: 3 Mar 2016

Post by Gpx • 04 Mar 2016, 22:36

Please note that 18/11/2015 23:36:41 UTC = 19/11/2015 00:36:41 Paris time (just to explain why we have a difference)

Gpx
Posts: 9
Joined: 3 Mar 2016

Post by Gpx • 04 Mar 2016, 22:37

I do not have issue when i copy/paste files from C: to K: in Windows Explorer

Gpx
Posts: 9
Joined: 3 Mar 2016

Post by Gpx • 05 Mar 2016, 01:14

To be complete, my K drive is indeed a virtual drive connected through webdav and recognize as a FAT drive

User avatar
Zenju
Site Admin
Posts: 4696
Joined: 9 Dec 2007

Post by Zenju • 05 Mar 2016, 10:53

Gpx wrote: Here are the screenshots. Quite self explanatory but it's in French though so tell me if you need translation.
The problem is not due to an invalid date, but caused by the WebDav drive not supporting modification times. The error message was misleading, though and I've fixed it to not warn about the date in this case.
Gpx wrote: I do not have issue when i copy/paste files from C: to K: in Windows Explorer
Unlike FFS, Windows Explorer ignores failure to write modification times.

Gpx
Posts: 9
Joined: 3 Mar 2016

Post by Gpx • 05 Mar 2016, 15:15

Thanks Zenju

Meaning taht next version of FFS will not warn about that and will sync smoothly ?

User avatar
Zenju
Site Admin
Posts: 4696
Joined: 9 Dec 2007

Post by Zenju • 05 Mar 2016, 17:48

No, it will still fail, but the error message will not be misleading anymore. :>

Gpx
Posts: 9
Joined: 3 Mar 2016

Post by Gpx • 11 Mar 2016, 12:17

Zenju

Do you think you could implement a drowngraded mode for FAT drive ?

If NTFS source drive contains x files and FAT destination drive contains 0, then at least it should be able to copy those x drive to the destination drive.

We could also imagine that we could compare file size and overwrite any file on the destination drive for which the size differs. That is what I would need to be honest ;-)

Many thanks

Greg

User avatar
Zenju
Site Admin
Posts: 4696
Joined: 9 Dec 2007

Post by Zenju • 11 Mar 2016, 12:31

If you don't have reliable file times you can directly do a compare by file size. Generally, having broken modification file times on the NTFS source side is not something that FFS should ignore. (Where did they come from?)

softgear
Posts: 1
Joined: 8 Nov 2016

Post by softgear • 08 Nov 2016, 02:34

I have met the same error.
After I changed the file system of destination from exFAT to NTFS, I worked well.
I think FFS should resolve this problem for exFAT.