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


----- Original Message ----- 
From: "RaphaŽl Quinet" <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
> 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

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.

Gimp-developer mailing list

Gimp-developer mailing list

Reply via email to