Re: Your backup is unsafe!

Kent Overstreet (kento@pobox.alaska.net)
Sun, 01 Aug 1999 20:40:44 -0800


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/