>> That makes the question really "should the iso9660 filesystem code
>> learn how to write iso9660 images?"

> I don't know much about how isofs is laid out, but two points come to
> mind:

> - On a read-only filesystem, you don't need a free/in-use bitmap.
> - You also don't need indirect blocks, since each file could
>   conceivably be laid out linearly.

> A truly read/write isofs would need to maintain the above - the first
> is obvious, and the second is required to support independent writes
> from more than one process.

> So the question really is: "**can** the iso9660 filesystem code be
> made to write iso9660 images as a general-purpose filesystem?"

Of course it can.  If the iso9660 format doesn't include space for such
things, they can be maintained in-core, rebuilt at mount time if
necessary.

Not that I necessarily believe this would be a good thing to do.  I
haven't looked at it enough to feel qualified to hold an opinion on
that point.  I suspect it wouldn't, though, largely because it would
make (read/write) iso9660 mounts rather expensive, in terms of both cpu
and memory to hold those data structures.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu