Modification log stores up to 9 records

[hakanai]

I made 12 modifications to the disk in separate sessions to see what would happen to the modification log.

Turns out that the original record for formatting the image remains, but other modification entries get pushed off the bottom of the log such that the latest one is always first.

00000000  6e 65 77 66 73 5f 61 70  66 73 20 28 37 34 38 2e  |newfs_apfs (748.|
00000010  35 37 2e 31 39 29 00 00  00 00 00 00 00 00 00 00  |57.19)..........|
00000020  3e 17 0f d6 2a ac 32 15  02 00 00 00 00 00 00 00  |>...*.2.........|

00000030  61 70 66 73 5f 6b 65 78  74 20 63 6f 6d 70 69 6c  |apfs_kext compil|
00000040  65 64 20 40 20 41 70 72  20 31 33 20 32 30 31 00  |ed @ Apr 13 201.|
00000050  55 4c 3b 69 2c ac 32 15  1d 00 00 00 00 00 00 00  |UL;i,.2.........|

00000060  61 70 66 73 5f 6b 65 78  74 20 63 6f 6d 70 69 6c  |apfs_kext compil|
00000070  65 64 20 40 20 41 70 72  20 31 33 20 32 30 31 00  |ed @ Apr 13 201.|
00000080  d0 fd fb 4b 2c ac 32 15  1c 00 00 00 00 00 00 00  |...K,.2.........|

00000090  61 70 66 73 5f 6b 65 78  74 20 63 6f 6d 70 69 6c  |apfs_kext compil|
000000a0  65 64 20 40 20 41 70 72  20 31 33 20 32 30 31 00  |ed @ Apr 13 201.|
000000b0  6d 5c 2f 2e 2c ac 32 15  1b 00 00 00 00 00 00 00  |m\/.,.2.........|

000000c0  61 70 66 73 5f 6b 65 78  74 20 63 6f 6d 70 69 6c  |apfs_kext compil|
000000d0  65 64 20 40 20 41 70 72  20 31 33 20 32 30 31 00  |ed @ Apr 13 201.|
000000e0  4e d2 e5 10 2c ac 32 15  1a 00 00 00 00 00 00 00  |N...,.2.........|

000000f0  61 70 66 73 5f 6b 65 78  74 20 63 6f 6d 70 69 6c  |apfs_kext compil|
00000100  65 64 20 40 20 41 70 72  20 31 33 20 32 30 31 00  |ed @ Apr 13 201.|
00000110  de 92 fa f2 2b ac 32 15  19 00 00 00 00 00 00 00  |....+.2.........|

00000120  61 70 66 73 5f 6b 65 78  74 20 63 6f 6d 70 69 6c  |apfs_kext compil|
00000130  65 64 20 40 20 41 70 72  20 31 33 20 32 30 31 00  |ed @ Apr 13 201.|
00000140  18 4e 4f d6 2b ac 32 15  18 00 00 00 00 00 00 00  |.NO.+.2.........|

00000150  61 70 66 73 5f 6b 65 78  74 20 63 6f 6d 70 69 6c  |apfs_kext compil|
00000160  65 64 20 40 20 41 70 72  20 31 33 20 32 30 31 00  |ed @ Apr 13 201.|
00000170  81 24 fd b7 2b ac 32 15  17 00 00 00 00 00 00 00  |.$..+.2.........|

00000180  61 70 66 73 5f 6b 65 78  74 20 63 6f 6d 70 69 6c  |apfs_kext compil|
00000190  65 64 20 40 20 41 70 72  20 31 33 20 32 30 31 00  |ed @ Apr 13 201.|
000001a0  d1 2f 8a 9b 2b ac 32 15  16 00 00 00 00 00 00 00  |./..+.2.........|

[hakanai]

The bit I can't quite account for is the way there is both a thing at the start which looks like an xid and a thing at the end which looks like an xid.

I left it the way it previously way, taking the xid before the name of the modifying application, but maybe it's actually the other way around, and the 0x1 at the start is not an xid at all...

[ydkhatri]

In my tests, it appears that the 0x1 may likely be an 'initial_xid'. Putting an initial_xid field before 'formatted_by' and removing the 'unknown' one after 'modified_by' fixes this. Now you will see correct values in these structures.

[ydkhatri]

Got more insight into the 0x1 value. It is not an xid at all. Those 8 bytes store the encryption flags. Bit0 = 1 = Not encrypted For encrypted disks, Bit0 = 0 and other bits are set. I've usually get encryption_flags=0x8 for encrypted disks. That resolves this.

[hakanai]

I just did a manual merge so some manual verification that the overall result is still fine would probably be a good idea...

[tempelmann]

Is this merge request still valid? Or outdated?

[cugu]

Same as #34. Might still be valid, but would require some work and testing.