Found A Bug Relating To Datetime Modified

[bez]

I've spotted a bug relating to date modified on files. 

 

I was having an issue where the sync on the destination computer would never stop indexing the same files over and over.

 

After a lot of head scratching I've noticed the date modified on the files in question were either in the future (2043) or in the past (1970)

 

This is because they were taken from a digital cameras which didn't have the date/time set properly.

 

The files sync'd over OK but they were set to 1970 on the destination computer or some other datetime that didn't match. The indexer got stuck in some kind of loop, maybe the files hashed ok but then something was failing with regards to the date?

 

Anyway I fired up FreeFileSync which instantly picked up on this, copied and overwrote the files and now BTSync is happily sat there without the indexing problem.

 

Here's one of the files affected... hope it helps someone out (and hope some devs fix it soon)

 

[GreatMarko]

Sync - in fact most software - won't recognize dates before midnight 1 Jan 1970 (also know as the "epoch"), therefore any file that has somehow got a timestamp before the epoch - which from your screenshot, appears that the year is 1907!!!? - will have its timestamp set to the lowest valid time, which is 1 Jan 1970 at midnight.

 

I would suggest the bug is less with Sync - which is handling invalid dates correctly - and more with your digital camera if it recognizes 31 July 1907 as a valid date/time!

[bez]

There were some also set to 2043 which is a valid datetime, albeit in the future, but they failed the same as the 1907 ones.

 

Unfortunately Windows doesn't adhere to epoch time, I just edited the timestamps on a file - the minimum is 1st Jan 1601, so it needs to cope.

 

 

Edit: 

January 1, 1601 NTFS, COBOL, Win32/Win64 1601 was the first year of the 400-year Gregorian calendarcycle at the time Windows NT was made.^[12] Edited April 2, 2014 by bez

[RomanZ]

bez,

 

In general it is very bad idea to set the future mtime for the files as BTSync relies on the mtime when adding files to its internal tree. If files are in far future, they will be always consider as "latest" version regardless on where their copies were changed - and will roll back the changes made.

[Wim]

I'm having a similar issue, and I'm pretty sure it's Sync (version 1.3 for Windows) related. I have several folders set up where my computer is the only one with read/write access and everyone else is read only.

 

I have two files that had future modified dates. I changed the dates to sometime in the recent past and Sync recognizes them as modified and continues to see them as updated every 10 seconds or so.

 

When I look at these files' properties again after that, the modified date is now 1958.

 

So I move the files out of my shared folder, modify the dates again, check the dates afterwards and they are exactly as I put them.

 

I now look at the shared folder, and these files are there as .!sync files, 0 bytes and Sync is not downloading them from anyone. They are just there. So I delete the .!sync files, and move the files with the corrected dates back into the sync folder.

 

A few seconds later Sync sees the new files, adds them, and modifies the modified date back to 1958 within these files.

 

I have tried deleting the shared folder in sync, delete the .syncid file and re-share but the same thing keeps happening. I cannot delete the files that are already shared since my Sync doesn't have the originals (unmodified future date) anymore, and putting these back in with a fixed date throws Sync into an endless loop informing me that the files have been updated.

 

I do not know how to resolve this at this time short of creating a new shared folder and starting over entirely.

[okibcn]

I've found a similar problem with a group of JPG with mdate in year 2098. The procedure I did was:

 

1 - Close BT Sync in all sites.

 

2 - Change the date of the files with invalid mdate with BulkFileChanger in all sites (it is a nice Windows software that doesn't need to be installed, AKA greenware).

 

3 - Run BT Sync again in all sites.

 

In case BT Sync restores the old invalid date, then the solution wuld be removing the sync folder with invalid files in all sites, do step 2 and after that create a new secret and sync the folder tree with the new secret. This will take more time, but is a definitive solution.