I no longer maintain this patch and have not since before 2000. I leave this page up because people still link to it. A more recent version of File I/O is no longer available. It looks like the link I had there is dead as of July 2010.
It is now my opinion that integration between the LambdaMOO server and OS services is better and more safely done with external daemons and higher levels of abstraction than direct file access.
One example of this would be reading and writing files by talking to an HTTP or FTP server via the existing server support for making outbound TCP connections.
Many uses of this patch involve moving some MOO data out of the db and into disk files. This introduces a new problem of checkpointing the on-disk file store along with each db checkpoint. As shipped, the MOO server stores its entire state in the .db file when it is checkpointed and checkpoints are atomic. This is no longer true when some of the MOO’s state is stored in external files.
This may have been useful when a typical MOO process was the largest thing a machine might run (tens or even low hundreds of megabytes in an age when a desktop machine had 8M or less). Not so much now — even a very large MOO isn’t going to put any sort of memory pressure even on even fairly small VPSes and certainly not on a dedicated physical machine.
The patch was written to integrate MOO with some processing so the server could pass information to another process via a file rather than over a socket. Now it is no big deal to interact with a web service or other TCP service and send even fairly large files — Waterpoint even supports core DB extraction via a web page where the in-db web server generates and sends the pre-core database to an HTTP client.
The new maintainer broke the link and I never had the latest code. A quick web search suggested no source for the latest code for this patch — I don’t want to put my ancient pre-new-maintainer code up because it’s got known bugs that the new maintainer had fixed (which is how he won new-maintainership).