>>> What I'd like to see is this dealt with in a SENSIBLE way,
>>> so both operating systems see both versions of the name.
>>> That way, all such problems vanish.
>>> One obvious way round this would be to have the file always
>>> appear under the MSDOS version of the name, with the LFN
>>> version appearing as a hard link to it. Throw that in, and
>>> the problem mentioned above goes away since tar then sees
>>> and records both versions of the name.
>>> This would place two limitations on the hard link facility:
>>> 1. Only one hard link to any given file. Therefore, the
>>> link count field in long directory listings is limited
>>> to show either 1 link (for a file without an LFN) or 2
>>> links (for a file with an LFN).
>>> 2. The hard link must be in the same directory as the file
>>> it points to.
>>> I don't see either of those limitations as being any more
>>> restrictive than what's already in use.
> 3. We are getting hardlinks to directories. Bummer.
I have to admit that I'd overlooked that fact, and that is not a good
idea at all. However, I find it hard to believe that the current
broken behaviour of having otherwise valid names called invalid just
because they happen to coincide with a non-visible name for an
existing file.
Based on your comments, I would tend to think that hard links would
solve the problem for non-directory entries, but they are clearly not
suitable for directory entries. In my book, SymLinks are a non-starter
simply because they have too many pre-requisites relating to cross-
device links.
Allowing for this, my suggested solution would be along the lines of
using the mode bits to deal with the problem, based on something along
the lines of the following:
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.
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.
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.
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. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
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/