Re: VFAT rename

Kevin M. Bealer (kbealier@stny.lrun.com)
Thu, 20 May 1999 00:14:50 -0400

Alexander Viro wrote:
>
>
>On Sun, 16 May 1999, A. Wik wrote:
>
>> On Sun, 16 May 1999, Alexander Viro wrote:
>>
>> >
>> >
>> > On Fri, 14 May 1999, A. Wik wrote:
>> >
>> > > It's impossible to rename a file on a VFAT filesystem if
>> > > the only difference between the old and new names is case
>> > > (eg. longfilename and LongFilename). The operation is
>> > > cancelled in fs/namei.c because the lookups return the
>> > > same dentry for both names. What would be the most
>> > > reasonable way to fix this?
>
>[snip]
>
>> Surely, it can be fixed - how about a mount-option to enable to
>> enable the fix?
>
>Sorry, I didn't realize what you were asking for. Comments re POSIX are
>correct, but in that case everything is much worse. What kind of
>semantics do you want here? Two dentries for the object at the same
>moment? Sorry, no. Especially for directories. Feel free to propose a fix,
>indeed, but I'ld be *very* interested if you could find a clean way to do
>it. Clean as in "not introducing local DoS holes". It's that serious.
> Case-preserving & case-insentive is a kludge and a bad one. It really
>doesn't map on the UNIX semantics and IMO it will always remain a kludge.
>Something will not work and lack of feature is better than exploitable
>race.
> Again, feel free to provide a clean solution. Frankly, I'm very
>sceptical wrt existence of such beast.
>

I'm not familiar with the dcache mechanics, and I would guess that you
are correct (that it can't be made to work) but to help us users
understand the reasons,

1. What problems would happen when renaming "Foo" to "foO" that would
not be open when renaming "Foo" to "baR"? On any rename, compliant
programs should expect the file name to disappear indefinitely (and
another name to appear) so it shouldn't matter if it is not available
from the directory for a few cycles.

2. What semantics would be broken by renaming "Foo" to "foO" that would
not be broken by renaming "Foo" to "unreadable_directory/uniqueXYZ0001"
and then back to "foO"? I'm not saying this is the implementation,
just a semantics question.

If we view the rename as a rename to a different name, we expect all the
references to the existing code to break. Any program that is prepared
for two consecutive renames should be able to handle the semantics, if
we choose semantics that are in line with #2 above. This is what the
user will do anyway if they are doing this by hand, so if we make it
automatic, then programs will not have to handle "rename works, but
it depends on the name".

As for DOS semantics, it would be helpful to me (for something else
I am working on) to know if there are same-name issues.

Kevin

-----kbealier.at.stny.lrun.com-------------------------------------
THE LESSER-KNOWN PROGRAMMING LANGUAGES #12: LITHP
This otherwise unremarkable language is distinguished by the
absence of an "S" in its character set; users must substitute
"TH". LITHP is said to be useful in protheththing lithtth.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/