Life is completely mad at the moment. I've still had a little bit time to write code, but work is full on and after hours is crazieness too, so I haven't had a lot of time blog. Let see if we can get up to speed.
I'm working to finish off
fat.handler. That pretty much means write support. In the last week I've implemented the remaining "read" bits of the handler. File protection bits are mapped as best as is possible, file timestamps are converted and the free space on the volume is reported properly.
In addition to this I've been reading as much as I've been able to find about the filesystem format. Between that work, the official Microsoft documentation and the Wikipedia entry, I think I have a pretty good idea of how things are supposed to work. Its actually a nice filesystem to be learning on - nothing too fancy but enough clever bits to make it interesting.
One thing I'm not understanding too well is the existing structure of
fat.handler. I think I follow it, but it really seems to be a quick-and-dirty job for read access. It caches lots of stuff, which is fine - caching is a good thing - but the structures that are used for caching don't really seem suited to writing changes back to disk. The code is also quite spaghetti'd, and isn't well documented at all, which makes for a pretty unpleasant experience.
One of my plans for filesystems is a generic block-caching layer, which will make it so that filesystems won't have to cache blocks themselves at all. So, my intention is to remove all caching from
fat.handler and hit the disk every time. This will make things vastly slower, at least initially, but it will let me understand the code enough to implement write support. I can then add caching back later once I have everything clean and documented (and working!).
I think I'll write something soon about those future plans. Basically it'll be a busy year, but my plan is to come out at the end with AROS having rock-solid disk/file stuff. That would make me happy :)