I am having a problem clearing a dup inode.
V6 had almost no tools for automagically fixing file system corruption.
To do it, you need to i) understand how the FS works (see:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man5/fs.5
but it's pretty simple); ii) understand what the few tools (dcheck; icheck;
clri) do; iii) dive in.
I recall I used to use 'adb' a lot, to manually patch things when there was a
problem, so you'll want to study up on the 'db' syntax (no 'adb'
in vanilla
V6, but for this, they are basically equivalent):
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man1/db.1
You'll have to use the non-raw version of the device (the raw version can only
read/write complete blocks), and then judiciously use 'sync' to flush the
updated blocks out to the 'physical' disk. (There are some corner cases where
data is stored elsewhere, such as when one is patching the inode of an open
file, but I'm going to ignore them.)
# icheck -s /dev/rp0
'icheck -s' only rebuilds the free list; it doesn't help with any other
error
(e.g. a block being assigned to two different files).
4244 dup; inode=323
Which is probably what is happening here. 'icheck':
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/icheck.8
is not telling you what _else_ is using that block, because it has already
forgotten that by the time it discovers this second claimant (it only keeps a
bit array of 'used' blocks).
# icheck -b 323 /dev/rp0
Err, you wanted to say 'icheck -b 4244' to find out who else was using block
4244.
I'm not sure if 'fsck' would fix these; I have a V6 one, if anyone wants
it.
The 'easy' way to fix this is i) copy the second file to somewhere else, ii)
delete the original, iii) re-build the free list (because the duplicate block
will now be in both the first file, and the free list), iv) examine both files,
and see which one has the smashed contents.
I'll turn this into a 'Fixing damaged V5/V6 file systems' article on the
CHWiki.
Noel