On Wed, May 26, 2010 at 01:35:39PM -0000, Alex Onic wrote: > Public bug reported: > > Binary package hint: unison > > I want to sync a large collection of music files to an external hard > drive. In operation I get a strange behavior which _only_ occurs since > the update to Lucid Lynx (and not on older versions). > > Though the two paths are identical, Unison suggests to sync from right > (ext drive) to left (HD) for only two directories and their contents. > Unison should not suggest to transfer anything. > > (1) When choosing to sync --> I get an error message for every file similar > to this: > The file .unison.07 - The Turning > Point.mp3.e541ccee2d3ec03e843542d15cdfee49.unison.tmp was incorrectly > transferred (fingerprint mismatch) > > (2) When choosing to sync <-- I get the error message for each file: > Destination updated during synchronization
It looks like the files has been modified in identical ways on both drives, but without their last modification times being changed accordingly. Some programs for editing mp3 tags are known to do this. Then, Unison has now way of detecting the changes on the HD without rescanning the file contents (each file has kept the same size, inode number and last modification time). The external drive is probably formatted with the FAT filesystem. As this filesystem does not provide stable inode numbers under Linux (the inode numbers will changes for instance if you unmount then remount the drive), Unison has rescanned the contents of the files on this drive and detected the changes. When propagating changes, Unison will always rescan the contents of the target files before updating them, in order to be sure that they are really unchanged: the fastcheck optimization is not trusted at this point. Thus, in case (2), it detects that the files on the HD have also been modified, and reports that the destination has been updated. In case (1), the files are accurately copied from the HD to the external drive, but then Unison notices that their contents is not what it expects (because the updates on the HD has not been detected). Therefore, it reports a fingerprint mismatch. Thus, this does not seem to be a Unison bug. Besides, there does not seem to be any way to improve Unison in order to avoid this kind of issue, as there is no way do detect the changes in this case short of always rescanning the file contents, which is slow. Maybe the error messages could be improved somewhat. Also, Unison 2.40 will force a rescan of the file at the next run when this kind of error happens, so it will recover on its own of this kind of problem. You can recover from this situation by running Unison once with option "-fastcheck false" (I believe this is suggested by Unison in case (2), together with the "Destination updated during synchronization" error message). Then, it will rescan all files and notice the identical updates on both drives. You should be able to speed up update detection on the external drive by adding "pretendwin = true" to your profile. With this option, the inode number changes on the FAT filesystem will not be considered by Unison as indicating a possible update, triggering a file content scan. On the other hand, setting this option will make Unison miss on both drives the kind of file change you have experienced... -- Jerome -- Unison reports false file changes and can't transfer files https://bugs.launchpad.net/bugs/585842 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
