inodes are no longer constant across VFAT mounts at kernel 2.2.14

[Khimenko Victor]

In <20000125120112.D3559 en hexagon> Nimrod Zimerman (zimerman en mailandnews.com) wrote:
> On Sun, Jan 23, 2000 at 09:57:37PM -0000, Norman Back wrote:

>> However if tar -g had been used instead of tar --newer dir2's contents would
>> be archived correctly because it checks the name and inode against the
>> 'snapshot' file.
>>
>> Any other sugestions? I don't like the idea of retaining an old version of
>> kernel simply for archiving. It is possible that some later enhancement of
>> linux (or fat filestore) will preclude its use in the future.

> You could use a "simple" set of scripts to get a statistically current
> snapshot of the system.
> It goes something like that (I used an identical scheme to backup my own
> systems, which used to consist both of ext2 and of fat filesystems):

> 1. Generate a list of all files on the system, with all the changeable
> details of them that you care about (filename, symbolic link information,
> mode, uid, gid, rdev, size, mtime). You can even store an hash of all
> regular files, if you feel paranoid. To do this, I used 'find' with a
> perl script.

> 2. Backup said list of files, and store the list as 'current backup' (I used
> afio).

> 3. At some point in time when you wish to make an incremental backup,
> regenerate the list of files, and figure out what lines appear in the new
> list but not in the old list (I used 'comm').

> 4. Backup the new list of files, and store the list along with the original
> list as 'incremental backup i'.

> 5. Repeat from stage 3 ad infinitum.

> There probably are publicly available scripts that do this same thing, by
> the way. I'm certain I didn't invent anything...

> My set of scripts are in a terribly fuzzy state, especially as I didn't use
> them for quite some time. If you ask, I can send them to you (after proper
> removal of embarrassing parts).

tar -g should do exactly this :-) Unftunatellyone thing considered as
changeable details is inode number (understandable) and it does not work
anymore since FAT does not have inode numbers or anything suitable to
generate them :-/ IMO better way is just small patch to tar ...

P.S. To Viro: is it possible to add ioctl to find out "first cluster" number ?
Then tar can use it instead of inode number for FAT. Even if "first cluster"
number is not inode number it IS suitable as replacement for this particular
case... Or such ioctl already there ?



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/