Re: [rdiff-backup-users] a bug when using Cygwin

[Andrew Ferguson]

Qiqi Yan wrote:
> Hi all,
> 
> I mentioned the problem in a previous post. But I think it might be
> better to start off a new topic for a little more attention, because
> it could cause files in the backup folder to go missing. It happens
> on rdiff-backup 1.1.7 with cygwin, and possibly other case
> insensitive platforms.
> 
> 1. create file "a" in a folder. 2. run a backup with very default
> setting. now file "a" is created in the backup folder. 3. rename "a"
> to "A" in the source folder. 4. run a backup again. now you will find
> that neither file "a" or file "A" is in the backup folder!
> 
> strangely, if you start with an "A" file, and rename it to "a" in the
> second backup, the "a" file will still be in the backup folder.
> 
> I don't know if by using --override-chars-to-quote appropriately,
> this could be solved. Actually I never got --override-chars-to-quote
> to work on cygwin... anyone has any successful examples?

What we've got here is another bug in rdiff-backup. This one is
particular to backing-up a case-insensitive filesystem to another
case-insensitive filesystem.

>From some quick tests, I *think* we can avoid this bug by simply adding:
--override-chars-to-quote "A-Z;"
every time you call rdiff-backup. This suggests that the correct test in
fs_abilitites.py is to simply quote whenever the backup destination is
case-insensitive.

Now, clearly if a user is going insensitive <-> insensitive they can't
have both "file_name.txt" and "File_Name.txt" in the same directory at
the same time, and thus quoting shouldn't be necessary. This is why the
test behaves as it does now. So why does quoting the capitals solve the
problem?

Let me explain what's going on under the hood:

On first backup, rdiff-backup sees the file "a" and copies it to the
destination. So far, all is good.

On second backup, rdiff-backup sees that the file "a" is missing and
that a new file named "A" exists. To synchronize the backup, it first
copies the new file named "A" to the destination. Then it tries to
delete the (apparently missing) file named "a". HOWEVER, everything goes
to hell since the filesystem treats "A" and "a" as the same file -- whoops!

On a side note, this explains why when you change the order of your test
("A" first, then "a"), you still had "a" at the end of the second
session. rdiff-backup deleted "A" and then created "a" (as opposed to
the other order in the previous setup), simply because "A" comes before
"a" under an ASCII sort.

Thus, quoting the capitals keeps this whole mess from happening. I'm not
sure if that's the best, most correct fix, however. In an ideal world,
rdiff-backup would simply process everything in the correct/safe order
as needed, but unfortunately I don't have the time to dig into this for
a few weeks. It will involve crafting a lot of strange scenarios and
really exercising both the backup and restore code.

Best,
Andrew

PS -- Qiqi, you shouldn't hit the current_mirror bug if you use this
setup, either.

-- 
Andrew Ferguson - address@hidden