DO NOT REPLY [Bug 3444] Cygwin files trashed when they only differ in the case of the name

[bugzilla-daemon at dp3.samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=3444





------- Comment #1 from hashproduct at verizon.net  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.