Re: mv can't change filename case on case-insensitive file systems

[Eric Blake]

> (I reported this issue on the bug tracker on Savannah, but it looks like
> sending bug reports to this mailing list is preferred, so I'm repeating it
> here.)

The bug-tracker forwards all edits to this list, so you just repeated
yourself.

> 
> On Cygwin using non-managed mounts (and presumably other operating systems
> when using a case-insensitive file system), it's not possible to use
> Coreutils mv to change the case of a filename; mv reports that they are the
> same file.
> 
> The underlying Cygwin rename() function does support this functionality.

Although it is an unstandardized behavior.  Consider - should
rename("Foo", "foo") be a no-op when stat("Foo") and stat("foo")
resolve to the same file?  Reading just the POSIX rename(2)
requirements seems to say yes (it requires rename to be a no-op
when both names resolve to the same inode, ie. no case change
allowed); but reading the stat(2) requirements says it is undefined,
since a case-insensitive filesystem violates POSIX in the first
place.  Mac HFS is the other biggest case-preserving
case-insensitive system out there; can anyone comment on
whether rename(2) is a no-op or changes case when given two
case-wise distinct spellings of the same file?  Also, what about
FAT filesystem access under Linux?

I'd like to know whether platforms agree on semantics,
before deciding whether a patch is even possible.

One of the more interesting manifestations of the problems with
case-insensitive systems was this example culled from the mentioned
thread on cygwin:

$ mkdir foo
$ mv -T foo Foo

Rather than being a no-op (because it is two spellings of the
same file) or changing the case (as was argued above might
be reasonable behavior for case-insensitive systems), it
triggers the coreutils shortcut that since foo and Foo give the
same stat results, they must be hard-linked, so it attempts
unlink("foo"), which is invalid on a directory.

Another example:

$ touch foo
$ ln foo fool
$ mv foo Foo
$ echo ?oo*
fool

Oops - because foo has a link count > 1, and because stat
returned the same results, unlink("foo") was called, getting
rid of "foo" in all forms rather than just renaming foo.  Yes,
the data is preserved in fool, but it seems odd to have all
references to foo disappear merely because of the hard link.

-- 
Eric Blake