https://bugzilla.samba.org/show_bug.cgi?id=3444
------- Comment #1 from [EMAIL PROTECTED] 2006-01-25 16:38 MST ------- It's pretty clear that the trouble is the case insensitivity of the filesystem. In fact, I reproduced this behavior on a vfat partition mounted on Linux: mkdir test1 test2 touch test1/Foo touch --reference=test1/Foo test2/foo rsync -avvvii --delete-after test1/ test2/ Note that statting foo, Foo, or FOO will find the destination file, but readdir gives its name as foo. When rsync decides to copy test1/Foo, it stats test2/Foo and finds a matching file: it has nothing to do. Then it scans test2/ for things to delete and finds an extraneous file test2/foo, which it deletes. So --delete-after can cause data loss. When --delete-before or --delete-during is used, rsync deletes the destination file as unmatched and then copies the source file all over again; this is inefficient, but it does not cause data loss and it brings case on the destination into line with case on the source. One way to fix this data loss problem is to detect the case insensitivity of the destination filesystem and compare files case insensitively with the entries of the file list when deciding whether to delete them. But that's really ugly. Having rsync remember the i-node numbers of the files it creates and skip deleting those files might work, but it's still a hack. For the moment, avoid --delete-after on filesystems that accept inexact filenames, including case insensitive ones and ones that perform translation/canonicalization of character encodings (Mac OS X?). -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html