inodes are no longer constant across VFAT mounts at kernel 2.2.14

[Khimenko Victor]

In <000101bf65ec$dc6bc200$0100a8c0 en local1> Norman Back (norman.back en tesco.net) wrote:
> Hi David & Alan

>>
>> Maybe tar --newer [date] can do the trick for you. Of course, the best
>> idea is not to use fat/vfat to store anything important...

> Hmm. I have a dual boot PC and use linux to back everything up to another
> box. Unfortunately I need to run Windows 95 and it doesn't seem to work with
> ext2. I've had another look at tar --newer. It isn't good enough. It can
> miss files requiring archive.

> For example:
> mkdir dir1
> # place lots of files under dir1
> tar --newer
> mv dir1 dir2 # dir2 has dir1's modification time
> mkdir dir1
> # place lots of files under dir1
> tar --newer # does not archive dir2 so dir2's files will be lost on recovery
> of drive.

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

Then fix tar. If feel that you can do [v]fat with constant inodes across mounts
and eliminate all races then contact Viro (viro en math.psu.edu). He was unable to
do so. There are just not enough information about file on vfat to give it
constant inode number (remember: inode should NOT be changed when opened file
is truncated to zero and then filled again so you can not use cluster number
for such inode). If you not feel that you can do that then try to fix tar.





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