[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
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.
Gimp-developer mailing list