![]() The binaryĪmount of "information" is the same, the difference is just its Physically saves local time, while NTFS physically saves UTC time. What the source of this problem is at its lowest level, we have FAT that Speaking about it, just had some (potentially) great idea: When thinking about "Ignore 1-hour file time difference" option, but the last time IĬhecked it allowed to slip away files that where changed in less So, while we have to deal with them, let's try to find a solution.įinally, I have not checked the recent implementation of the Nearest future there is a place for old FS's like FAT, FAT32, etc. ![]() You can't dictate users to use only FS that support UTC. >but either avoiding them or solving them. the solution is not hiding the differences, >other, so there is not much to win in this case. ![]() >performance characteristics as if one file is copied over the >2.2.2 a full binary comparison of two files should show similar Hour differences may slightly increase the number of cases that Never heard of them, but this very specific case could be covered Time zone shifts are not only full hours but may be as small I need a simple back up of current files to someīackup storage. Proposal in my initial post could make a sense.īTW, while I see the place for "automatic" mode, I have actually Only if program can't make comparison of UTC timestamps the And, I guess, here we're talkingĪbout the latter case (at least one FS doesn't support UTC). Of them don't use UTC - it's a tough case, resulting in potentialĬonflicts in automatic mode. ("absolute" time stamps) and not a local time. >cannot deduce a sync-direction for the current sync. >because the files were not "in sync" last time, therefore it The next sync in automatic mode will bring up a conflict the solution is not hiding the differences, but eitherĪvoiding them or solving them. and the number of files processedĢ.2.2 a full binary comparison of two files should show similar performanceĬharacteristics as if one file is copied over the other, so there is not muchĬoncerning problem 1. The probability of a failed detection of different files (with same size) increases with 2. Time zone shifts are not only full hours but may be as small as quarter of an hourģ. The next sync in automatic mode will bring up a conflict because the files were not "in sync" last time, therefore it cannot deduce a sync-direction for the current sync.Ģ. Timeshift occured (either due to dst or timezone travel), files have a different date, but are marked as equal. This idea basically would be the generalization of the current "+-1h" settingġ. This assumption may eliminate a lot of cases for furtherĬontent comparison (which could be costly) and speed up the sync. Versions of a file within 24h with exactly the same minutes and seconds. Why 2.2.1 could be acceptable? The probability of saving two different If it's the same - finally compare the content (MD5?). And in such case:Ģ.2.1 - simple consider they are the same (simple, fast and quite effectiveĢ.2.2 - compare file sizes. If it is - they could be the same version. is the difference equals exactly 'N' hours AND is equal or less thenĢ.2. If they're the same - go to next filesĢ.1. Improved by implementing this simple way:ġ. To separate only changed files from the rest - I think it could be But keeping focus at the main goal here. By some reasons I can't add any posts there.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |