later that day
I’m currently checking in some fixes that I believe will stabilise the file writing. There was a few places where I’d got the math wrong when generating directory entries which would sometimes result in weird corrupted filenames (depending on what was on your disk before I incorrectly wrote directories onto it).
Assuming its right, things are really starting to wind down on this code. Here’s a vague todo list, for my reference and yours :P
- Implement
RENAME_OBJECT
and theSET_*
commands.SET_FILE_SIZE
is the only interesting one, because it means allocating or freeing clusters to match the size. None of them difficult. - Implement file notifications. This is a mechanism where an application requests to be notified when a file or directory changes. Conceptually its not difficult - just a list of listeners attached to every lock (and shared between duplicate locks). I think it would get a little hairy if I did it with the lock management functions in the state they’re in, but I haven’t started my cleanup of
lock.c
yet so I’ll make sure I factor it into my planning. - Implement write-back caching.
- Cleanup the DOS-side code (mostly
main.c
anddisk.c
) - Break out the rest of
packet.c
intoops.c
- Make sure locks are being tracked properly. This should resolve the disk change issue on native too (where two volumes appear when you change the disk).
- Fix the crash in native where you try to use the handler directly with
DF0:
(though technically this is an issue with the way DOS andpacket.handler
interact.
After that its time for the next thing. Volume manager, ext2 or something else - I’m not sure yet.