rsync - Sep 2017 - [Bug 13061] New: File lost on case-insensitive file system

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

            Bug ID: 13061
           Summary: File lost on case-insensitive file system
           Product: rsync
           Version: 3.1.3
          Hardware: All
                OS: Windows 7
            Status: NEW
          Severity: major
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: towo at towo.net
        QA Contact: rsync-qa at samba.org

On a case-insensitive file system (Windows/cygwin):
I renamed a file to upper case, then ran my backup script using
rsync -r --delete-after src /backup

I got this error message:
rsync: send_files failed to open
"/cygdrive/d/home/tools/mined/src/n/x":
Permission denied (13)
IO error encountered -- skipping file deletion

The old (lower case) file was finally deleted in the backup area, but the new
(upper case) file had not been copied to it.
(It was copied of course when I ran rsync again.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

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

--- Comment #1 from Kevin Korb <rsync at sanitarium.net> ---
Are you saying that it deleted a file AFTER saying "IO error encountered --
skipping file deletion"?

Maybe you need some --itemize-changes to make sure.  Unfortunately, this is a
limitation of the filesystem and rsync *should* have simply left the file
untouched (and never be able to update it) unless --ignore-errors.  The
behaviour you describe is what --ignore-errors should do.

The --fuzzy option might possibly help here.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

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

--- Comment #2 from towo at towo.net ---
Actually, I was too eager minimizing the test case, sorry.
I can only reproduce it reliably with additional options -vltoD :
rsync -vrltoD --delete-after src /backup

Also sorry for the bogus error message, actually it looks like:
building file list ... done
deleting src/vivaldi

(where a file src/Vivaldi exists, a file /backup/src/vivaldi existed before and
is then deleted)

Attempts to remove options for reproducing the issue expose weird behaviour;
for example, if I strip "ltoD":
rsync -vr --delete-after src /backup

it also happens initially, but if I repeat the test, it does not happen again
until I revert to the previous options (of course with a fresh test case setup
each time).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

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

--- Comment #3 from Kevin Korb <rsync at sanitarium.net> ---
That makes even less sense.  Rsync doesn't do anything to the source at all
unless --remove-source-files and it only does that after it successfully
transfers a file.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

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

--- Comment #4 from towo at towo.net ---
The file /backup/src/vivaldi is deleted, not src/Vivaldi

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

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

--- Comment #5 from Kevin Korb <rsync at sanitarium.net> ---
OK, now I understand what is going on.  It is a 2-part problem...
Rsync sees the source file as new because it does not exist in the target but
it fails to copy the file because the name conflicts with an existing file. 
That should abort the deletions (not sure why it isn't) but in the end rsync
sees the existing file as superfluous because there is no matching filename on
the source.

The --fuzzy option might fix this.  Using --delete-before instead of
--delete-after would delete then replace the file.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.