Re: Your backup is unsafe!

Nathan Hand (nathanh@chirp.com.au)
Mon, 2 Aug 1999 01:32:59 +1000


On Sat, Jul 31, 1999 at 10:07:01AM +0100, Robert de Bath wrote:
>
> This will save the fakename but not the 8+3 name, if you do a restore
> linux will _normally_ regenerate the same 8+3 name, but not always.
>
> "So what" you say, well it's like this; there are LFN programs that store
> the 8+3 name not the long one, for example MS Office. If everything has
> gone just right and the 8+3 name of one of the few bad files changes the
> restore will fail for no visable reason.
>
> So I'd like to put in a feature request to have a translation mode where
> the entire name is visable. Perhaps something like this ...
>
> If no longname use msdos translation
> If shortname is "~1 " version of longname use longname
> Otherwise use shortname=longname
>
> or perhaps something even more ugly. The aim is obviously that a
> backup+restore will preserve _both_ names guarenteed.

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.

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.

To make this work the mapping "file" (more like a proc entry really) can
have entries which don't correspond to existing files yet. If you create
a longfilename which has an existing entry, it uses that short name. Now
restores work and preserve both of the original short and long names.

The magic file must of course be something which interacts directly with
the VFAT filesystem driver. It isn't a real file, it's a set of hints to
VFAT on how to handle open/creat/rename/unlink on long filenames. It may
need very strange rules governing how read/write interacts with it.

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