| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| sneaker_net_sync [2013/06/09 00:03] – external edit 127.0.0.1 | sneaker_net_sync [2017/01/01 20:05] (current) – external edit 127.0.0.1 |
|---|
| |
| Click ''Start'' to apply the delta file. | Click ''Start'' to apply the delta file. |
| | |
| | ===== Edge Cases ===== |
| | |
| | There is a possible situation that would prevent Sneaker Net Sync from detecting that a file has changed. When a computer program modifies the contents of a file the operating system (Windows) automatically updates the modified date of the file. However, a program can also directly set the modified date to anything. A program could theoretically read the modified date of a file, change the contents of the it and then set the modified date back to its original value. This would be very strange behaviour indeed. If the length of the file did not change, Sneaker Net Sync would not detect the change and would not ever re-sync the file. |
| | |
| | This edge case is very unlikely to happen, but if it was a concern, hash values could be used. This would prevent the edge case, but using hash values dramatically slows down the indexing and delta creation process. |
| | |
| | Well... almost. Hash values do not //fully// eliminate the edge case. While it is incredibly unlikely that two files with different content would have the same hash value, it is technically //possible//. Sneaker Net Sync uses a 128-bit hash, which means that there are approximately 3.402 × 10<sup>38</sup> possible unique hash values. Assuming truly random distribution, the chances of two files having the same hash value is about the same as throwing three pins at the Earth from space such that they land at some random point on the Earth's surface, and all three land within 1 mm of each other (the Earth's surface area is approximately 5.1 × 10<sup>20</sup>mm<sup>2</sup>). |
| | |
| | If this possibility is unacceptable, the only option would be to fully recopy **all** the files every time a re-sync is done. Even this would not absolutely and completely guarantee that the files are synced - there could be read or write errors while copying the files to and from the transport media. |
| |
| ===== Daylight Saving Issues ===== | ===== Daylight Saving Issues ===== |
| ''None'': Nothing special is done. **All** files will be resynced when going into daylight saving time and back to standard time. Typically, this will take a long time and will create a huge delta file and/or may require multiple resyncs to 'catch up'. Once the files are resynced, the file modified dates will match between the master and secondary computers. | ''None'': Nothing special is done. **All** files will be resynced when going into daylight saving time and back to standard time. Typically, this will take a long time and will create a huge delta file and/or may require multiple resyncs to 'catch up'. Once the files are resynced, the file modified dates will match between the master and secondary computers. |
| |
| Only use this option if Sneaker Net Sync is not affected by the daylight saving issue, or there a concern about the [[#the_edge_case|edge case]]. | Only use this option if Sneaker Net Sync is not affected by the daylight saving issue, or there a concern about the [[#the_daylight_saving_edge_case|edge case]]. |
| |
| ''Ignore time differences'': If the name, file size and hash (if used) match and the modified date is different by the amount specified by the ''Time Difference'' setting (+/- 3 seconds) the difference will be ignored and the file will be considered to be 'in sync'. Nothing special will happen when going into daylight saving time or back to standard time. Files added or modified during daylight saving time will have modified dates that do not match the master computer's files. These files will also have modified dates that are incorrect relative to the files that were //not// modified during daylight saving time. The incorrect modified dates will never resync. | ''Ignore time differences'': If the name, file size and hash (if used) match and the modified date is different by the amount specified by the ''Time Difference'' setting (+/- 3 seconds) the difference will be ignored and the file will be considered to be 'in sync'. Nothing special will happen when going into daylight saving time or back to standard time. Files added or modified during daylight saving time will have modified dates that do not match the master computer's files. These files will also have modified dates that are incorrect relative to the files that were //not// modified during daylight saving time. The incorrect modified dates will never resync. |
| ''Time Difference'': The amount of time that should be ignored or corrected. | ''Time Difference'': The amount of time that should be ignored or corrected. |
| |
| ==== The Edge Case ==== | ==== The Daylight Saving Edge Case ==== |
| | |
| | If the Time Zone Options is set to anything other than ''None'', there is a known edge case that could potentially cause Sneaker Net Sync to fail recognise that a file has changed - although the chances of this occurring are very remote. It would have to happen like this: |
| | |
| | - A file is modified on the master computer. |
| | - Sneaker Net Sync creates a delta file. |
| | - The same file is modified, without changing its length, one hour (+/- 3 seconds) after it was originally modified. |
| |
| | Because the modification date of the file will have increased by one hour and the length remained the same, Sneaker Net Sync will either ignore the change or update the modified date without updating the contents. |
| |
| | If this edge case is a concern, the Time Zone Options can be set to ''None'' or hash values can be used. |
