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

[John Cowan]

Eric Blake scripsit:

> 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)

That's *very* surprising, although I agree that it is Posix.  I would
have confidently expected that after a successful rename(foo,bar) that
foo would be a pathname that no longer refers, but it is not so:

address@hidden:/tmp$ touch foo
address@hidden:/tmp$ ln foo bar
address@hidden:/tmp$ perl -e 'rename("foo","bar")'
address@hidden:/tmp$ ls -i foo bar
2047220 bar  2047220 foo

> since a case-insensitive filesystem violates POSIX in the first
> place.  

That being so, I think one should apply the spirit rather than
the letter of rename(), and follow the first sentence:

        The rename() function shall change the name of a file.

That says to me that "rename("foo", "Foo") should Just Work.
Or more to the point here, that since it doesn't (and see below),
that "mv" should at least Just Work.

Note that even though file operations are case-insensitive on
insensitive file systems, things like file completion in bash
are not, so having the right apparent case can matter.

> Also, what about FAT filesystem access under Linux?

FAT is always upper case and the driver forces it to
lower case.  VFAT ignores attempts to change case
with rename(), in conformity to Posix.

-- 
Well, I have news for our current leaders       John Cowan
and the leaders of tomorrow: the Bill of        address@hidden
Rights is not a frivolous luxury, in force      http://www.ccil.org/~cowan
only during times of peace and prosperity.
We don't just push it to the side when the going gets tough.  --Molly Ivins