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

    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.

    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.025 / U:2.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site