Talk:Comparison of file synchronization software: Difference between revisions

Revision as of 19:33, 16 November 2014

Revision as of 20:28, 16 November 2014

Line 106:

I think it's very important to address the capabilities/shortcomings of applications that cannot detect differences in padded files and take appropriate or reasonable user-defined actions.

By "padded', I mean files that deliberately have extra space already included in them to accommodate rapid updates without requiring assessment of hard drive resources. The technique of padding is ubiquitous, if not standard, in application configuration files and audio files like MP3 ANDand FLAC files, and has been so for well over a decade if not longer.

While the uninitiated may think this is a nit, a technicality or something that only the obsessive worry about, then I can reliably inform you that the real situation is completely the opposite for the typical user. For example, what if you edit the name of an artist in your music file and then save it to your local hard drive. Upon backing up or syncing your music files, would you expect that your change would be recognized and the appropriate update occur? I would hope so. But no...for many of the apps in this wiki article. Not only would the change not be detected, but many of these apps will see a file mod date change and no file size change, automatically assume the file dates where wrong, then overwrite the file mod date of the backup ___location to mask the detection of a difference. While in decades prior to 1990 this may have been a reasonable default action because of operating system and network issues in working with backups and external hard drives, in reality such issues were solved before even the MP3 codec was invented.

For the apps that can;t handle this well, they typically only have one way to detect real differences in added files: run the app by recalulatingrecalculating all checksum data on all files. So what woulddwould typically be a 1 minute effort becomes a multi-day effort. Or force the user to manually select files they somehow "knew" changed but weren't detected as changed to force an update. Neither are reasonable day-to-day. Put another way, one can always manually wipe out an entoreentire backup or sync ___location and start from scratch each time that will probably take less time than a full checksum backup for sync effort, but no one needs an app for the method of wiping and redoing from scratch every time.

To be clear, this affects any user trying to not only deal with song files, but anyone trying to backup application configuration files - padding is an effective way to speed up small file changes without engaging in OS resource allocation and file moving efforts that can really slow down small configuration changes. I suspect many mainstream PC users use applications with configurations that they don't want to lose and therefore backup or sync, but if any are padded as is typical, any backup or sync app not designed to deal with padded files will at some point likely have a major issue.