[Re-sending this because I sent it to Kevin instead of the list. Grumble...]
On Fri, 15 Aug 2003 07:45:28 -0500, "Kevin Myers" <[EMAIL PROTECTED]> wrote: > I could be mistaken, but it doesn't seem that a file system with an > extensible size would be a big problem... It may be a problem with _existing_ filesystems. > We make a request to store a "file" in our "file system within a file", and > what we want to store exceeds the available capacity of our present file > system. No problem. Our file system's space request handling routine > detects the out of space condition, and makes a request to the OS to extend > the size of our real file, then proceeds with allocating the desired space > in our internal file system. [...] The whole point of Tor's proposal was to use an existing filesystem, such as FAT, Minix, UDF, ISO9960, etc. Using the Linux loopback devices (for example), one coudl easily mount these filesystems-in-a-file and use the standard tools to work with the files they contain. We could design a filesystem that can be extended dynamically, but then we lose the ability to use existing drivers and tools. As I mentioned in my previous message, we could of course increase the size of a filesystem such as FAT, but that would basically require a new copy of the file in which we extend the file allocation table or inode table to leave enough room for the new sectors. The same tricks would have to be used when we want to shrink the file. In other words, this is not trivial. I'd rather have some kind of archive format. If we want to replace an element in the archive by another one that is larger, we can append the larger one at the end of the archive, update the index and leave some unused bits in the middle. That would not waste more space than the filesystem idea. In both cases, we could have an option for defragmenting the file if we do not want to waste space with unused bits or unused sectors. Or we simply re-create a "clean" file when using the "Save As" option. This is exactly what is done by several software packages, including MS Office. -Raphaël _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
