On 01/21/2013 06:05 PM, Toby Thain wrote: Thanks - that did let me infer the directory data block format which I'd not seen described anywhere else. The three big unknowns I have at the moment are: 1) how to calculate the offset within the dump to each cylinder group header. I can find them by searching for the CG magic number (which is at offset 0x4 within each) but I don't know how their offsets are calculated, or stored in the superblock, or stored elsewhere (at least one text that I read implied that they were stored in a lookup table completely separate to the superblock) 2) how to calculate the offset from each CG header to the start of that CG's inode table. It seems to be 8192 bytes in all the UTek dumps that I have, but I don't know if it's always 8192 bytes for any UFS implementation, or even that I can assume it's always 8192 for UTek. 3) how inode data block pointers work. e.g. how the address stored in each block pointer is translated to a physical offset from the start of the partition dump. In one example that I have here, I've managed to find the data block containing the root directory, but the address which it's at seems to have no simple correlation that I can see to the data block pointer in the corresponding inode. cheers Jules

Wiadomo?? napisana przez Jules Richardson w dniu 22 sty 2013, o godz. 02:36: Using http://svnweb.freebsd.org/base/head/sys/ufs/ffs/fs.h?revision=243250&vi… as a reference, you should be able to calculate this using cgbase(). cgimin() lblkno(), IIRC. -- If you cut off my head, what would I say? Me and my head, or me and my body?

On 01/22/2013 09:46 AM, Phil Budne wrote: Yes, although these are from UTek V, and there seems to be some quirk of that particular OS which makes them not quite compatible with any of the UFS variants that Linux supports. In fact, the UFS driver in recent kernels doesn't even seem to work at all - I can mount the images, but any attempts at access results in errors. Older 2.4.x kernels do much better - to the point that back in ~2006, when I was last looking at this, using the 'sun' variant of the UFS driver seemed stable and I'd left it at that - but in some recent testing I've now seen read ops occasionally barf on certain files and directories even then; there's obviously something in the UTek implementation which trips the driver up (and some change seems to have happened in the UFS driver within the last few years which appears to have left it unable to read any of the data at all) I've recently acquired a few more fs dumps from a couple of different sources/machines, which is why I'm looking at this again - but it also means that the probability of them all being corrupt (rather than just "not-quite-compatible") is low. Hence my desire to try and pick them apart in user-land, outside of the kernel UFS implementation, to try and work out what's causing them to fail. (they all seem to be "ufs-1", incidentally, in that there's no ufs2-type information in the superblock) cheers Jules

Steven Hirsch <snhirsch at gmail.com> writes: affs works fine on 3.4.24 -- I've been using it to shovel data back and forth to my A1200 using a CF card lately. -- Adam Sampson <ats at offog.org> <http://offog.org/>

On Tue, 22 Jan 2013 10:23:58 -0600 Jules Richardson <jules.richardson99 at gmail.com> wrote: Hint: NetBSD has rump(3): rump itself makes it possible to run unmodified kernel components in a regular userspace process. [...] Examples of different use models are running file system drivers as userspace servers (see p2k(3)) and being able to write standalone applications which understand file system images. And as NetBSD is a BSD your chances are good that it can read BSD FFS / UFS. ;-) -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}