lkml.org 
[lkml]   [1999]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Your backup is unsafe!
    On Mon, Aug 02, 1999 at 08:16:51AM -0800, Kent Overstreet wrote:
    > Nathan Hand wrote:
    > >
    > > On Mon, Aug 02, 1999 at 11:31:38AM +0100, Robert de Bath wrote:
    > > > On Mon, 2 Aug 1999, Nathan Hand wrote:
    > > >
    > > > > The problem isn't straightforward. Simply stated, VFAT has two names for
    > > > > a file, both are valid, both must be preserved, only one is visible, but
    > > > > both are usable at all times. This does not map onto any UNIX filesystem
    > > > > so some magic is needed.
    > > >
    > > > Under _Windows_ both are valid. Do you really think this brain dammage
    > > > should be kept in Linux? There is no reason for the short name to be
    > > > visable _except_ when there are interactions with DOS, this comes down
    > > > to dosemu, samba and backups.
    > >
    > > In retrospect I have to agree. It's clearly better to only show the long
    > > filenames and have special "VFAT aware" programs to handle backups. This
    > > can be done via ioctl, a /proc interface, etc. It's a robust solution.
    > >
    > > > > How about a magic file in each VFAT directory which contains mappings of
    > > > > long to short filenames. You only see the long names using standard UNIX
    > > > > file I/O. Then backups work, because you backup the magic file too, so a
    > > > > restore will put the correct short/long mappings back.
    > > >
    > > > Yes, I thought of this but the coding would be horrific. I think this would
    > > > work out to be just the same as using a directory by directory sfn_backup,
    > > > and IMO it's better to do it in userspace and keep those horrors from the
    > > > kernel.
    > >
    > > Yes, I agree. The existing Linux VFAT filesystem is clean, UNIX-like, it
    > > hides the major braindamages, and it fails in very few cases. Far better
    > > to solve specific problems (like VFAT backups) with specialised tools.
    >
    > Ok, I've been following this thread for awhile, and I think I missed the
    > first email, but I don't get something: Why do we need to store the 8.3
    > version in a backup? It's a pretty simply algorithm to get the 8.3
    > filename from the LFN one, why not put the 8.3 version back when you
    > restore to the vfat partition, and completely hide the 8.3 filename?

    $ touch /dosc/longfilename # longfilename -> longfi~1
    $ touch /dosc/longfilename234 # longfliename234 -> longfi~2
    $ rm /dosc/longfilename
    $ yourbackup
    $ rm /dosc/*
    $ yourrestore # longfilename234 -> longfi~1

    And you pick longfilename234 to generate the same encoding (it's not
    actually 234). Silly, contrived, proves the point.

    > Most of the other ideas - symlinks, hardlinks, are *extremely* messy and
    > kludgy, and special vfat aware tools. It shouldn't be hard for Linux to
    > generate the 8.3 name from the LFN version - when you restore (or are
    > writing files to a vfat filesystem in general) you make sure Linux puts
    > in both names. In a previous post, I showed how Windows uses directory
    > entries with the hidden, system, and volume label attributes to store
    > the LFN name, the entries are then ignored if you boot into, say DOS
    > 6.22. Now I could be talking out of my ass, but this whole thing just
    > doesn't make sense to me, especially some of the solutions that have
    > been proposed. If I'm wrong, feel free to flame me with better
    > information :)

    The whole point is that the proposed solutions are trying to make an
    idiotic design into a sensible one.

    It's not possible. VFAT is stupid. Let it fail. Trying to fix it can
    only make Linux-VFAT idiotic as well.

    Linux-VFAT makes the existing idiotic design look like UNIX. This is
    as good as it needs to get. Do any VFAT backups in Windows.

    My opinion only, etc. I just talk a lot, I don't write VFAT :-)

    --
    Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
    Phone: +61 2 6230 1871 Fax: +61 2 6230 1515 E-mail: nathanh@chirp.com.au

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:53    [W:0.024 / U:4.120 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site