inodes are no longer constant across VFAT mounts at kernel 2.2.14

[Alexander Viro]

On Tue, 25 Jan 2000, Khimenko Victor wrote:

> > You could use a "simple" set of scripts to get a statistically current
> > snapshot of the system.
[snip the description of tripwire]
 
> > There probably are publicly available scripts that do this same thing, by
> > the way. I'm certain I didn't invent anything...

You bet.

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

First of all, there is such ioctl, but it's quite a mess (as any ioctl,
for that matter). FIBMAP. However, hacking _that_ into tar is idiocy - you
don't want to pollute the generic tool with such mess. Let it do _one_
thing, and do it good. GNU tar is already featuritis-ridden - just check
the list of options (oops, no decent manpage - GNU project at its usual)
and you'll see what I mean.

Look: if you need incrementals - make a tool that would take whatever data
it wants to keep and print the list of files due to be backed up. And
feed the results to tar/cpio/whatever. It's not like the idea of pipes was
new, after all.

BTW, no other tar does -g, and rightfully so. It's _not_ a work for tar
- it's (a) format-independent, (b) useful for other purposes, (c) can be
trivially off-loaded into separate program, (d) may require modifications
for oddball filesystems/local policy/whatever and those changes have
_nothing_ with tar. I.e. it should be done separately. But GNU folks love
monolitic monsters... Could somebody tell RMS about pipes and fork(2),
please?


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