[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Moving hosts: corrupt library (failed inode signatu
Re: [Gnu-arch-users] Moving hosts: corrupt library (failed inode signature validation)
Tue, 26 Oct 2004 18:26:11 -0500
Mozilla Thunderbird 0.8 (Windows/20040913)
Zenaan Harkness wrote:
I guess the same thing would apply when moving between filesystems.
Is there a way to migrate a revlib from one fs/partition/host to
(My workstation died last Saturday and so I've set up a new box -
grabbed stuff off the old HDD, including the revlib. Of course (now I
think about it) I get the above error.)
As of now, I've blown away my old revlib and just rebuilding, but for
future reference, I'd like to know if this can be done. I guess it would
be something like a "tla revlib-fsck" :)
As far as I know, there is *no* way to move a revlib or a pristine tree.
The reason is that the only way to know it is pristine is to do a "stat"
and compare it to the "stat" of when it was created. If it has been
modified, it is immediately assumed to be potentially corrupted.
Moving within a filesystem doesn't change stat. But moving between
filesystems is a copy. While you can preserve some information, at the
very least the inode sig and device id will change, meaning something
will change, which could be interpreted as corruption.
It might be nice if tla had something like "restore-pristine", or
something such that if you were very sure that the tree is pristine you
could force it.
However, there is already discussion about changing how inode-sigs
works. Before 1.2.2 the device was monitored, which caused problems in
NFS. jblack's branch had a workaround for this, which I assume will show
up in 1.3.
But some other things. If you "touch" a file (not in the revlib), it
looks newer than the revlib. So tla has to do a diff on it to see if it
really is different. But tla doesn't update the revlib to match the
latest version of the file. So from then on tla *always* does a diff
against that file. (Until a commit type deal where the revlib finally
Also, the mode of revlibs is (was) not checked properly, so in a
hard-linked tree, chmod could corrupt your revlib, but it wouldn't know
about it. I don't know the state of this bug, but it's part of what
started the big discussion about what permissions should be tracked.
Description: OpenPGP digital signature