Hello,
I am trying to set the FileTimeTolerance to 0 at the moment. But it seems that this is not possible (I get a warning message telling me that the files are equal and therefore cannot be syncronized, but if they are equal, why do they appear in FFS?).
What I want to achieve is that:
- two files with same time (exactly same hour, minute AND second): do nothing
- one file one second older/newer than the other one: syncronize
I tried to solve this setting the FileTimeTolerance to 0, but this didn't work.
Can anyone please help?
Set FileTimeTolerance to 0 - doesn't work
- Posts: 6
- Joined: 10 Mar 2013
-
- Site Admin
- Posts: 7056
- Joined: 9 Dec 2007
You're probably seeing "Cannot determine sync-direction: No change since last synchronization". There was no change on either side therefore FFS cannot determine a direction, despite the files not being equal (due to your new file time tolerance value).
- Posts: 6
- Joined: 10 Mar 2013
Thank you so much, Zenju, for your answer!
So - when I got you right - the setting "FileTimeTolerance = 0" disables the comparison by date and just looks at the file size (which didn't change) and therefore replies with the error message you mentioned above?
So - when I got you right - the setting "FileTimeTolerance = 0" disables the comparison by date and just looks at the file size (which didn't change) and therefore replies with the error message you mentioned above?
-
- Site Admin
- Posts: 7056
- Joined: 9 Dec 2007
No, it's the same behavior, just the tolerance level is changed with the implications mentioned above.
- Posts: 6
- Joined: 10 Mar 2013
Thank you for answering.
In English, it is a little bit difficult to explain what I want to do, but I try it anyway :-)
I have two computers with slightly different time, so the time isn't exactly the same on both computers (the difference can be a whole minute sometimes and I don't want to compare the time before I start a sync). If I sync now, it could be (in 10000:1 cases, but it could be) that I immediately want to change a file on one computer after sync (and the computer on which I want to change the file runs a little bit "before" the time than the "last changed time" in the file).
So, in the file, there is ... let us say ... 12:30:33.
If I change this file without changing name or size of it on the "synced" computer at 12:30:33 (which is possible, as already mentioned), nothing happens ... that is okay, since the chance to change a file at the very same time than it was "last changed" without changing the file size is very low.
To allow only this case (which will hardly never occur), I changed the filetimetolerance to 0. So a change on the second "synced" computer at 12:30:32 or also 12:30:34 should be detected.
But with filetimetolerance set to 0, this doesn't work. I get the message you mentioned. Filetimetolerance = 0 just recognizes changes under or above 2 seconds. If the "last changed time" in the file and the system time on the computer on which I change the file has a difference of only one second, it doesn't recognize this change.
I hope I could express what I want to do with my 2 computers :-)
In English, it is a little bit difficult to explain what I want to do, but I try it anyway :-)
I have two computers with slightly different time, so the time isn't exactly the same on both computers (the difference can be a whole minute sometimes and I don't want to compare the time before I start a sync). If I sync now, it could be (in 10000:1 cases, but it could be) that I immediately want to change a file on one computer after sync (and the computer on which I want to change the file runs a little bit "before" the time than the "last changed time" in the file).
So, in the file, there is ... let us say ... 12:30:33.
If I change this file without changing name or size of it on the "synced" computer at 12:30:33 (which is possible, as already mentioned), nothing happens ... that is okay, since the chance to change a file at the very same time than it was "last changed" without changing the file size is very low.
To allow only this case (which will hardly never occur), I changed the filetimetolerance to 0. So a change on the second "synced" computer at 12:30:32 or also 12:30:34 should be detected.
But with filetimetolerance set to 0, this doesn't work. I get the message you mentioned. Filetimetolerance = 0 just recognizes changes under or above 2 seconds. If the "last changed time" in the file and the system time on the computer on which I change the file has a difference of only one second, it doesn't recognize this change.
I hope I could express what I want to do with my 2 computers :-)
-
- Site Admin
- Posts: 7056
- Joined: 9 Dec 2007
When determining a sync direction in "two-way" mode there are actually four file time comparisons which need to be treated differently. Let's consider a single file pair:
1. if size and date of left and right file matches, considering "FileTimeTolerance", then there's nothing to do. Otherwise:
2. If the database entries for left and right files do *not* match considering "FileTimeTolerance", which could happen if striker settings have been applied in the meantime, this is treated as an error. Otherwise:
3. FFS compares the date on either side with the corresponding database entry. This does *not* consider "FileTimeTolerance": All FFS wants to know is if there was a change or not. However technically it must allow for 2 seconds tolerance which seems to be the lowest precision seen in practice when retrieving file times.
In your case, FFS finds that left and right sides currently differ, but when comparing both sides against their database entries it finds no change considering 2 sec tolerance.
1. if size and date of left and right file matches, considering "FileTimeTolerance", then there's nothing to do. Otherwise:
2. If the database entries for left and right files do *not* match considering "FileTimeTolerance", which could happen if striker settings have been applied in the meantime, this is treated as an error. Otherwise:
3. FFS compares the date on either side with the corresponding database entry. This does *not* consider "FileTimeTolerance": All FFS wants to know is if there was a change or not. However technically it must allow for 2 seconds tolerance which seems to be the lowest precision seen in practice when retrieving file times.
In your case, FFS finds that left and right sides currently differ, but when comparing both sides against their database entries it finds no change considering 2 sec tolerance.
- Posts: 6
- Joined: 10 Mar 2013
Thank you, again, Zenju, for your answer. Sorry for not reacting for such a long time.
If I translated and understoof you correctly, there is an "internal", technical mechanism (the "tolerance") in step three you mentioned, giving a tolerance of 2 seconds, no matter what I type in "FileTimeTolerance". So the 2 seconds is the closest I can get.
Did I get it? :-)
If I translated and understoof you correctly, there is an "internal", technical mechanism (the "tolerance") in step three you mentioned, giving a tolerance of 2 seconds, no matter what I type in "FileTimeTolerance". So the 2 seconds is the closest I can get.
Did I get it? :-)
-
- Site Admin
- Posts: 7056
- Joined: 9 Dec 2007
Yes, step three uses a hard-coded tolerance of 2 seconds. Theoretically 0 seconds would be a better setting: Irrespective of what "FileTimeTolerance" is set to, if there is a change in file time on one side compared to the database entry, then this file indeed was modified irrespective of the precision that particular file system uses to store file times.
(the only exception are daylight saving time/ time zone issues on FAT which report different file times, although there was no change).
The problem for FFS is, that in order to get the correct file time after copying, it would have to read it once more after copying finished. This is one additional file access, that is redundant if the target file system stores file times with at least 1 second precision.
(further complication: the file time retrieved directly after copying may incorrectly return with higher precision than what was actually written due to OS buffering)
Unfortunately FAT stores only with 2 sec precision, so FFS allows for this tolerance to avoid having to access the file again after copying.
(the only exception are daylight saving time/ time zone issues on FAT which report different file times, although there was no change).
The problem for FFS is, that in order to get the correct file time after copying, it would have to read it once more after copying finished. This is one additional file access, that is redundant if the target file system stores file times with at least 1 second precision.
(further complication: the file time retrieved directly after copying may incorrectly return with higher precision than what was actually written due to OS buffering)
Unfortunately FAT stores only with 2 sec precision, so FFS allows for this tolerance to avoid having to access the file again after copying.
- Posts: 6
- Joined: 10 Mar 2013
Oh ... I see that a lot of points have to be taken into consideration when talking about the time of a file.
But, thanks to you, Zenju, I am able to understand a little bit better how FFS works now. And that I can leave the setting "FileTimeTolerance" set to "standard"; 2 sec.
Continue the good job here. And thank you very much!
But, thanks to you, Zenju, I am able to understand a little bit better how FFS works now. And that I can leave the setting "FileTimeTolerance" set to "standard"; 2 sec.
Continue the good job here. And thank you very much!
