[lkml]   [1999]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Your backup is unsafe!
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 /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.

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.

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

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


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

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


> Undead files, anyone? Should we change this behaviour if there
> is a file called .garlic?

Possibly if the mount option lfn_mode=garlic was passed.

Best wishes from Riley.

| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.100 / U:1.228 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site