tools: Preserve superblock between unpacking and re-packing

[Teufelchen1]

Addresses #13
"Wörks" for now. Needs clean up.

I'm not entirely happy with the solution I came up with but I didn't want to think even more about it, already wasted enough time without progress. The change is rather little so it wouldn't hurt that much, if this solution would be replaced/changed later.

What this basically does is:

• While unpacking an image, a copy of the superblock is written to /dest/.FATX-on-a-snake/superblock.bin
• When packing a folder into a new image, the source is checked if /src/.FATX-on-a-snake/superblock.bin exists, if so, it uses the given superblock. If not, it will create an empty one as usual.

[JayFoxRox]

I think this should be an explicit option for the paths. Otherwise a user might accidentally use a superblock which they did not want (at the risk of leaking private information like XBL accounts).
(Edit: I thought the path was relative to the script, not the FAT folder - so ignore the last sentence; however, I still think that the path should be explicit instead; otherwise your tools input/output will also be incompatible with other tools, as repacking would suddenly add metadata into the FAT where it shouldn't be. Explicit path also simplifies your codebase and is less error-prone)

Exporting the superblock should be optional as it just complicates it for some users.

When the superblock is imported, it should probably choose the cluster-size default. If the user explicitly picks a cluster-size that should probably overwrite the value in the superblock after importing the superblock.

[JayFoxRox]

Is 512 the sector size?
Isn't 32 the number of sectors per cluster?

[Teufelchen1]

Yes and yes. I see where you are going here - extract_blocks.py will hopefully be removed from the project soonish. Its only purpose is to provide easy accessible binary data for debugging purposes that are much much smaller then the original image and also hopefully do not contain copyrighted material. This allows me to ask users of FATX-on-a-snake to run this script and send me over the extracted files, so I can take a look. However, this is good enough for now but it will be unnecessary in the future, hence I want to remove it from the project. In order to do so I still have to gain more confidence that FATX-on-a-snake works good enough and is somewhat error resistant so it will be able to produce text-based, human-readable log output. That log can then be send over for remote debugging and will be guaranteed be free from copyright material.

My reasoning behind picking 512*32 instead of automatically calculating it is, that when this script is run, something is most-likely heavily broken. i.e. if a user attempts to open the xbox hdd from offset 0x00 it won't see the FATX magic bytes, yet, extract_blocks.py will happily run and extract the "should-be superblock".

[Teufelchen1]

I think this should be an explicit option for the paths.

Yes, agreed.

[..] I still think that the path should be explicit instead; otherwise your tools input/output will also be incompatible with other tools, as repacking would suddenly add metadata into the FAT where it shouldn't be. Explicit path also simplifies your codebase and is less error-prone)_

Yes.

Exporting the superblock should be optional as it just complicates it for some users.

Right.

When the superblock is imported, it should probably choose the cluster-size default. If the user explicitly picks a cluster-size that should probably overwrite the value in the superblock after importing the superblock.

Yeah, thought about that but hesitated. 🤔

Thanks for reaching out!