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:
[EMAIL PROTECTED]:/tmp$ touch foo
[EMAIL PROTECTED]:/tmp$ ln foo bar
[EMAIL PROTECTED]:/tmp$ perl -e 'rename("foo","bar")'
[EMAIL PROTECTED]:/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 [EMAIL PROTECTED]
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
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
