I could be mistaken, but it doesn't seem that a file system with an extensible size would be a big problem... 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. If OS reports out of space, then our file system reports out of space. Pointers used in our file system would be sized such that they could handle any reasonable size, perhaps 32 bit pointers to 256 byte blocks = 1 terrabyte capacity? Could even allow the block size to vary between different OS files to reduce wasted space for small "files" or support larger than 1 TB if necessary. BTW, Microsoft Windows registry is already basically an extensible file system within a file. A high end business product that I use called also SAS has something similar. I would guess there are others out there as well. s/KAM ----- Original Message ----- From: "Raphaël Quinet" <quinet@xxxxxxxxxx> To: <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx> Sent: Friday, August 15, 2003 6:57 AM Subject: Re: [Gimp-developer] Portable XCF On Fri, 15 Aug 2003 13:49:41 +0300 (EET DST), Tor Lillqvist <tml@xxxxxx> wrote: > I won't take any stand on either side (or how many sides are there?) in > the ongoing discussion, just air some fresh thoughts... <taking a deep breath of fresh thoughts> [...] > Now, what concept do the ar, zip, etc formats closely resemble? What > other thingie is it that you store files in? Yeah, file systems. > > Wouldn't it be neat to use a real file system inside the image > file... I.e. the image file would be a self-contained file system, > with the image components (layers, XML files, whatnot) as files. > > What file system would be good? I don't know. Presumably something as > small and simple as possible, but not any simpler. Maybe FAT? ;-) > Early V6 Unix style file system (but with longer file names)? Minix? > Or something completely different? ISO9960 (I have no knowledge of > this, it might be way too complex)? UDF? There is unfortunately one thing that most of these filesystems have in common: they are designed to store their data in a partition that has a fixed size. If you create such a filesystem in a regular file, you have to pre-allocate the space that you will need for storing your data. I have played a lot with loopback filesystems, which are useful for creating things like a read-only encrypted ext2 or FAT filesystem on a CD-ROM. Unfortunately, this only works well when starting with a 600+MB file in which I create the image of the filesystem. It is not possible (or not easy) for the filesystem to grow as needed. We could have a mixed solution, in which the GIMP would start with a relatively small file containing a filesystem and then replace it with a larger one whenever necessary. But this is not elegant nor efficient, so the solution involving some kind of archive file format is better IMHO. The proposal for XML + some kind of archive format looks good, except that I do not like the fact that all metadata (especially parasites) will have to be XML-escaped or encoded in Base64. Some parts may be stored as separate files in the archive, but that does not make the decoding easier because this means that some parts of the metadata are included directly while others are included by reference. The main advantage of using XML is that it can easily be debugged by hand. The other arguments that have been discussed so far (for or against XML) are not so significant. If we want something that can be easily read and edited by humans, let's go for XML. If we want something compact and efficient, let's go for something else. -Raphaël _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
