follow me into the caves!

In our last episode I was implementing FileLocks into dos.library. Well its done now. It took a couple of rewrites (if you can call mass search-and-replace operations a “rewrite”) as Pavel kept pointing out problems with my implementation (and rightly so), but its done. Trouble is, I can’t check it in. It turns out the aliasing of lock functions (like UnLock()) to their filehandle counterparts (like Close()) was actually getting hard-coded into binaries by the compiler. Adding the lock functions back to support locks is fine, but all existing programs are hardcoded to call Close() when they should call UnLock(). Thats fine if your locks and handles are the same, but as soon as they change, Close() suddenly finds itself being handed a lock. With no way to tell the difference, it pokes in places it shouldn’t causing a spectacular meltdown. And this only affects, oh, every program ever built for AROS that accesses files. All of them, in other words.

Staf Verhaegen is working on a pile of changes that will break the ABI and API, with a view to marking the ABI “stable” when he’s done. I’ll include these changes as part of that so that its only one round of user pain, but it does mean that I have to hold off on releasing it, which also means that I can’t really do much work on integrating packets. I can, of course, but I really don’t like holding on to uncommitted changes for too long - they tend to be painful to merge.

What I can do while I’m waiting though is start cleaning and restructuring our DOS to make supporting both packets and IOFS a breeze. Things like adding appropriate abstractions and such. I’ve started on this, with the first object of my affections being GetDeviceProc()

This function is the one that I consider to be the heart of DOS. Its quite simple: you give it a full file path, and it returns a structure that contains handle on the filesystem device (or task message port for packets) that has the file on it, and base lock that the file path is relative to. The real magic is that it automatically handles assigns, resolving late- and non-binding assigns on the fly. As if that wasn’t enough, it also has the somewhat minor task of getting new filesystems online on demand.

Thats a succint description of how its supposed to work. Reality rarely matches though. In AROS, it does assign handling all right, but doesn’t load filesystem handlers. It also crashes if you try to ask for a path without a volume specifier (ie something relative to the current dir) or use PROGDIR: (a magic name for the directory the program was started from). To cap it all off, the code is quite difficult to read, which makes it hard to fix.

Furthermore, there’s an internal function called DoName() which pretty much every handler call goes through that does basically the same job, but is much smarter. This duplication is completely redundant, particularly when the more advanced (and correct) functionality isn’t accessable to the user. So, I set for myself an initial goal of fixing GetDeviceProc(), then update all of DOS to use it and getting rid of DoName() completely.

I’ve just now finished the implementation, and as far as I can tell its working very well. It seems to produce the same results as the old version, but also handles the relative dir stuff without crashing. It expands and resolves assigns as expected. It also has placeholders for calling out to a function that can get the filesystem online if its not already. This code is coming - Pavel Fedin has been working hard on some DOS changes of his own to fix up our mount process. These should be appearing in SVN soon, and once its available I’ll merge my code and we’ll be well on our way :)

Lots to do while I’m waiting though. The next thing is to start moving functions away from DoName(). I’ll start small - Open() should be nice and simple.

Oh.