Subject: Re: restore(8) broken
To: None <current-users@sun-lamp.cs.berkeley.edu>
From: None <mycroft@gnu.ai.mit.edu>
List: current-users
Date: 06/18/1994 11:06:52
The problem with restoring dumps of old file systems is yet another
endian screw.  Basically, the old d_namlen field in the directory entry
has been split into d_type and d_namlen, and the actually value (which
was always <256) now overlays d_type.  restore(8) has no way of knowing
this, of course (which is why dump(8) should have always converted the
endianness to begin with, but it's too late now), and even worse, it has
no real way of knowing that the dump was from an old file system at all
(or at least, not that I can think of).

There are a number of potential ways to fix this.  I'll send more mail
when I decide which one is most `correct'.  B-)

(Hmmm.  Now that I think about it, has restore(8) ever been able to
restore dumps from the other endianness?  I'd think the inode numbers
would get byte-swapped, though perhaps this only affects restore by
inode #.)


------------------------------------------------------------------------------