This was meant to be a quick and dirty way for me to extract files from inside CON files for use in some online tools, but ended up taking about a week to complete. Never mind about the quick part then, but it's still dirty. I'm looking for nitpickers of the worst sort to go through this and help me bump up my Python and general programming work.
Here's a reference to STFS: http://free60.org/STFS
I tried adding some comments to explain things to myself, to readers here, and possibly to anyone unfortunate enough to use the code.
Quick overview of STFS:
The header contains the disposition of the master hash table (the one furthest up), the block of the file table and its length, as well as some other useful information. The file table contains a list of the files and directories, their starting blocks, and block lengths. Each block (hash table and data) is 0x1000 bytes long. Each data block is hashed, each filled hash table is hashed by the next table up. If there is only one hash table for a level and it's not filled, it's the master hash. The hashtable of a data block contains the next block in the stream.
Some of the above may seem obvious or redundant, but this is the first file system I've learned about and I don't know what's standard and what's not.
And the code: http://bpaste.net/show/ognpxaIrPamD6HwB5ROm/
edit: One of my main concerns is keeping the file as small as possible. I have a method in there, reallocate that fills up any unallocated blocks and then truncates the file. The way I did it, though, is pretty bad. It goes sequentially through each block of each file and if there's a free block below it, it switches them. The problem is that if, for example, block 2 is free, and blocks 5, 6, and 7 are used by a file, the method will get to block 5, move it to block 2, go to block 6, move it to block 5, and then finally move block 7 to 6. That's three moves, but it should have just moved block 7 to 2. The files can get pretty big, so I didn't want to store the paths in memory. Going in reverse order (which I can't because the next block is found by checking the hash table of the current block) wouldn't help either because the blocks aren't in order anyway. I would have to start from the last allocated block and move backwards, but I wouldn't know which block each block to be reallocated comes after, and I couldn't update that block's hashtable to tell the new position.
