Messages in this thread | | | Date | Sun, 01 Aug 1999 20:40:44 -0800 | From | Kent Overstreet <> | Subject | Re: Your backup is unsafe! |
| |
Kent Overstreet wrote: > > Riley Williams wrote: > > > > 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. > > I was just looking up how VFAT works, and yes, the 8.3 and LFN versions > of the filename are independant. The 8.3 version is stored normally, but > the LFN version is stored in directory entries with the hidden, > read-only, system and volume label attributes. This way, if you boot > into an old version of DOS, DOS only sees the 8.3 versions of the names, > but in Windows 9x the filesystem is handled by a special 32bit driver > that gives programs that can use it the long version.
- 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/
| |