Messages in this thread | | | Date | Mon, 2 Aug 1999 01:32:59 +1000 | From | Nathan Hand <> | Subject | Re: Your backup is unsafe! |
| |
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/
| |