Messages in this thread | | | Date | Sun, 1 Aug 1999 16:10:30 +0100 (GMT) | From | Riley Williams <> | Subject | Re: Your backup is unsafe! |
| |
Hi Alexander.
>>> 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/
| |