>
> Alexander Viro writes:
> > 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?
> >
> > Get a time machine and go into '89. Then bring a clue to POSIX authors.
> > In other words: it's POSIX-mandated behaviour. Bogus, but required.
> > It's a feature. That is, an idiotic bug in standard. Nothing to do here.
>
> First of all, vfat isn't even close to being POSIX. Why worry about one
> more little glitch? Normal POSIX filesystems allow "touch me ; mv me mE".
Albert, look for later posting. It's worse than just POSIX.
> Second of all, you are right about this being an idiotic bug.
> Following what seems to be a UNIX tradition (dup2, wait3, wait4),
> I propose the fix below. There might also be a "ren" shell builtin
^^^
> that calls it.
Trolling again, aren't you?
> RENAME2(2) Linux Programmer's Manual RENAME2(2)
>
> NAME
> rename2 - change the name or location of a file
>
> SYNOPSIS
> #include <unistd.h>
> int rename2(const char *src, const char *dst, unsigned flags);
>
> DESCRIPTION
> The rename2 function renames a file, moving it between directories
> if required. Symbolic links are followed for every path component
> except the last. If the destination already exists, rename2 will fail.
> Directories used as src need not be writable for ".." updates.
>
> The flags argument modifies rename2 behavior according to these bits:
[snip]
Remarkably ugly. Atomicity goes to hell with your R2_MKDIR and
the day when wildcard expansion will be done in a kernel will be the
last day when I'll think about touching said kernel. Period. YMMV, indeed.
If you want VMS you know where to find it. Albert, VMS traditions aside
(BTW, why won't you go pester FreeVMS folks?), there are very serious
problems with this thing.
Let me try to explain what I mean. VFAT has an extremely ugly
design bug, going back to VMS filesystem misdesign. Case-preserving but
not case-sensitive. It's fundamentally wrong thing. In effect, it makes a
capitalization not a part of name but a file attribute.
We can consider the capitalization as part of the name. That's
what mounting with 'strict' gives you. No problems at all. Thing becomes
case-sensitive.
We can consider the thing as case-insensitive and look at the
capitalization as an attribute out of our control (i.e. rename() has a
side effect of changing that attribute). And deal with inconveniencies.
We can consider all capitalizations as links. And eat flaming
death trying to deal with directories. It's fundamentally broken. Really.
We can try to twist ->lookup() semantics so that it would
distinguish the case of looking up rename() target and let the
vfat_lookup() create a dentry as negative. *That* can be done, but it
would make sense with the full nameidata implementation. I'm doing that,
but it's still in pre-alpha. Wait for a week or so.
POSIX bug wrt rename() is a totally different can of worms. *If*
we are considering target as positive (and pointing to the same file) we
are in for a big fsckup. Lots of them, actually. If we don't - POSIX
requirements (buggy as they are) simply do not apply to situation.
-
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/