Bug 13061 - File lost on case-insensitive file system
File lost on case-insensitive file system
Status: NEW
Product: rsync
Classification: Unclassified
Component: core
3.1.3
All Windows 7
: P5 major
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-09-28 19:20 UTC by towo
Modified: 2017-10-02 17:11 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description towo 2017-09-28 19:20:14 UTC
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.)
Comment 1 Kevin Korb 2017-09-28 19:30:20 UTC
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.
Comment 2 towo 2017-09-29 09:27:45 UTC
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).
Comment 3 Kevin Korb 2017-09-29 12:44:20 UTC
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.
Comment 4 towo 2017-09-29 13:40:23 UTC
The file /backup/src/vivaldi is deleted, not src/Vivaldi
Comment 5 Kevin Korb 2017-10-02 17:11:56 UTC
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.