> Hi Alexander.
>
> >> 1. Where a directory or file only has an 8.3 name, use that
> >> name as currently. No change is needed in this case.
>
> >> 2. Where a FILE has both an 8.3 name and a LFN, have both
> >> appear in the relevant directory, set as hard links to
> >> each other.
>
> > Wonderful. So you are going to accept the situation when
> > renaming one of the links makes another disappear?
>
> OK then, delete this option and replace the word "DIRECTORY" with
> "DIRECTORY or FILE" in option 3. I don't see the necessity for that,
> but if you feel uncomfortable with consistant behaviour...
>
> >> 3. Where a DIRECTORY has both an 8.3 name and a LFN, have
> >> both appear in the relevant directory, but with the 8.3
> >> name having mode 0000 and the immutable bit permanently
> >> set.
>
> > May I ask you, what for? What should happen if I'm saying
>
> > rm /mnt/shitfs/*
> > cp foo.bar.baz /mnt/shitfs/
> > cp /mnt/shitfs/* /tmp
>
> > should it copy the sucker twice, or what? What should happen
> > if I cp from one directory to another on VFAT filesystem?
>
> Try the following:
>
> Q> cd /mnt
> Q> mkdir a b
> Q> mount -t XXX /dev/fd0 a
> Q> mount -t YYY /dev/fd1 b
> Q> cd a
> Q> set > eg1
> Q> ln eg1 eg2
> Q> cp eg* ../b
>
> For it to be correct behaviour, the result of the last step should be
> INDEPENDANT of the values of XXX and YYY in the above. Anything else
> is BROKEN in my honest opinion.
>
Agree. That's EXACTLY why vfat is broken by design.
> Note that arguments about the ln step failing are NOT relevant, so
> don't waste your time on them. This is a discussion about the actual
> behaviour on fs's where at least one hard link is supported, as it
> would be on VFAT under the proposed semantics.
>
Unfortunatelly it's NOT hardlink. If I have file with two names on normal
fs (ext2) i can delete ANY at MY will. It's NOT hardlink.
> > Making cp or sh aware of *FAT is not an option, indeed.
>
> That's precicely why I believe the current (2.2.*) vfat behaviour is
> BROKEN and needs fixing.
>
You suggested three schemes already. All of them are with HUGE holes. If
you can sit down and write some scheme WITHOUT HOLES then we'll have
something to talk about. And no, testing broken 10000 schemes from your is
not an option.
> >> Can I also ask one question about VFAT which I am not certain
> >> about: Where an entry has both an 8.3 name and a LFN, is the
> >> 8.3 name set by the LFN to be specifically one thing?
>
> >> The reason I ask this is that my understanding of the way the
> >> VFAT fs works implies that the two names are effectively
> >> independant, and the only requirement attached to them is that
> >> they both point to the same file.
>
> >> If that is true, then given the file...
>
> >> Q> ANTIDI~1.LST => Antidisestablishmentarians.lst
>
> >> ...there would in theory be nothing wrong with doing...
>
> >> Q> mv ANTIDI~1.LST LOSERS.LST
>
> >> ...and ending up with...
>
> >> Q> LOSERS.LST => Antidisestablishmentarians.lst
>
> >> ...even though the Windows rename command doesn't do that.
> >> Likewise, if one was to then do...
>
> >> Q> mv Antidisestablishmentarians.lst unwanted.lst
>
> >> ...then one could validly end up with...
>
> >> Q> LOSERS.LST => unwanted.lst
>
> >> ...even though both sides are valid 8.3 names.
>
> >> There would of course be a requirement that one of the two
> >> names must fit the 8.3 format, and I'm not pretending
> >> otherwise.
>
> > And what should happen after mv foo ANTIDI~1.LST?
>
> On an EXT2 fs, what happens when one tries to move a file to an
> existing file that is marked IMMUTABLE (as I suggested above) ?
> Whatever happens there should also happen here.
>
I'm really sorry but you said right thing above: FILE is marked IMMUTABLE.
NOT it's name. If you mark FILE immutable via hardlink you'll see that
it's immutable for other name as well.
> > If you consider the whole thing as hardlinks you should end up
> > with (a) Anti.... with the same contents as it used to have and
> > (b) foo being renamed. Great, now we have to generate a new
> > short name.
>
> Why?
>
Since Anti.... can not be attached to ANTIDI~.LST anymore.
> > Undead files, anyone? Should we change this behaviour if there
> > is a file called .garlic?
>
> <RESPONSE TYPE=SARCASTIC>
> Possibly if the mount option lfn_mode=garlic was passed.
> </RESPONSE>
>
So far you proposed three cures for disaster. Each one is MUCH worser then
distater itself. Next time please cook up something less ugly...
-
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/