27 Mar
2005
27 Mar
'05
1:04 p.m.
On Sun, 2005-03-27 at 14:58 -0500, Scott Stevens wrote:
On Sun, 27 Mar 2005 14:11:14 -0500 (EST)
der Mouse <mouse at rodents.montreal.qc.ca> wrote:
I have a question about this that might be answerable by somebody here.
Awhile back I had a drive from an RS/6000 system and was attempting to
figure it out and get into it.
I decided that I would need to use another big-endian system to copy the
drive onto an image file to poke around in it. So I mounted the (SCSI)
drive on a Sparc box here (everybody should have a lunchbox sparc around
for such purposes) running NetBSD and used the dd command to make an
image.
Would it have made a difference if I'd used a little-endian system to
image the drive?
Generally, no. 'dd' just copies raw bytes as it sees them; it knows
nothing of any structure on top of the raw data (such as a filesystem
layout). It's only the code that you may then use to analyse the image
which needs to worry about byte order where necessary.
However, there do seem to be caveats. When I pulled raw data off my NCR
Tower's drive I had to swap bytes before anything made sense, but I
think that's an exception to the rule rather than the norm.
FWIW, 'dd' supports the 'swab' argument to swap adjacent pairs of bytes.
Why it's called swab rather than swap, I don't know - must have been
done that way for a reason...
cheers
Jules
Maybe
support under Linux is a little broken (I know already that
ufs/sun makes assumptions about the endian-ness of the filesystem in
some places)
Yes, if the filesystem really is a SunOS 4.* filesystem, it will be
big-endian. Your Linux FFS support has to be prepared for big-endian
data structures on disk, which if you're on a little-endian
architecture like i386 it may not be.