Hello, I am implementing a software to read JFS partitions in Windows/Mac OS X. Only reading, no writing involved.
It works already for many partitions, but someone sent me a disk, and this is something wrong with my interpretation of the JFS documentation or something like that, because for this particular disk, it doesn't work =( I read in this order: 1> Aggregate Map -> Always from offset A000 2> Fileset zero inode -> Always from offset D000 Here I read _xtroot: xtpage_t; in this inode to obtain the next address. See the screenshot: http://magnifier.sourceforge.net/tmp/jfs_fileset_zero_inode.png And the data that I read here (data in the comments): xtpage_t->xtpage_t = packed record xtpage_t->case Integer of 0: ( // struct xtheader { xtpage_t->next: le64; // 0 xtpage_t->prev: le64; // 0 xtpage_t->flag: Byte; // $85 xtpage_t->rsrvd1: Byte; // 0 xtpage_t->nextindex: le16; // 3 xtpage_t->maxentry: le16; // $12 xtpage_t->rsrvd2: le16; // 0 xtpage_t->self: pxd_t; // 0 xtpage_t-> ); xtpage_t->xad[2] => xad_t xad_t->flag: Byte; // 0 xad_t->rsvrd: uint16; // 0 xad_t->off1: Byte; // 0 xad_t->off2: le32; // 0 xad_t->len: array[0..2] of Byte; // 1 xad_t->addr1: Byte; // 0 xad_t->addr2: le32; // 2754 xad_t->addr calculated: 0x2754000 xtpage_t->xad[3] => xad_t = packed record xad_t->flag: Byte; // 1: flag */ 0 xad_t->rsvrd: uint16; // 2: reserved */ 0 xad_t->off1: Byte; // 1: offset in unit of fsblksize */ 0 xad_t->off2: le32; // 4: offset in unit of fsblksize */ 2 xad_t->len: array[0..2] of Byte; // 3: length in unit of fsblksize */ 1 xad_t->addr1: Byte; // 1: address in unit of fsblksize */ 0 xad_t->addr2: le32; // 4: address in unit of fsblksize */ } 2000 xad_t->addr calculated: 0x2000000 xtpage_t->xad[4] => xad_t = packed record brings addr 0x4000000 etc So my interpretation of the data is: A> xad[2] is the control page B> xad[3] is the Fileset Zero Inode Allocation Map Wierd that xad[2] has len=1 and xad[3] has offset=2 ... very wierd, as if the actual data is missing.... 3> So now I am at the Fileset Zero Inode Allocation Map at offset 0x2000000 Screenshots: http://magnifier.sourceforge.net/tmp/jfs_fileset_zero_map_1.png http://magnifier.sourceforge.net/tmp/jfs_fileset_zero_map_2.png >From it I read the following structures: inoext[0] ->pxd_t.len: array[0..2] of Byte;// 4 ->pxd_t.addr1: Byte;// 0 ->pxd_t.addr2: le32; // 0x2004 inoext[1] ->pxd_t.len: array[0..2] of Byte; // 4 ->pxd_t.addr1: Byte; // 0 ->pxd_t.addr2: le32; // 0x200C inoext[2] ->pxd_t.len: array[0..2] of Byte; // 4 ->pxd_t.addr1: Byte; // 0 ->pxd_t.addr2: le32; // 0x37B4 My conclusion is: A> The root inode is located at the address given by inoext[0] which is: 0x2004400 Now the problem: 0x2004400 is *not* the root inode =( It is an empty inode I manually searched the disk and I found the real Root Inode at 0x26400! Using this information I manually searched the disk and I concluded that 0x2000000 is probably also not Fileset Zero Inode Map =( I found an Inode Map candidate at 0x2B000 which has: inoext[0].pxd_t.addr2 = 0x26 But then I look again at the Fileset Zero inode D000 and I cannot find anything wrong with my reading of its data =( It doesn't feature the hex value 0x2B at all. Any ideas what I did wrong here? It must be something simple that I am getting wrong, but after hours and hours reading the hex data, I just cannot find =) Any tips appreciated. thanks, -- Felipe Monteiro de Carvalho ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Jfs-discussion mailing list Jfs-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jfs-discussion
