Re: Request: Test suite for EFS.

[Cory Watson <gphat mail midtnn net>]

Thanks for that long message, I jumped into the EFS discussion late and
was unable to lend any advice because I was unsure of the issue.

I suppose I could've read back, but thats no fun;)

Cory Watson
Systems Administrator
midtnn.net

On Thu, 24 Feb 2000, Mike Bond wrote:

> 
> On Thu, 24 Feb 2000 13:55:37 Guillermo S. Romero / Familia Romero wrote:
> > [Forward to the list if you think it is usefull, I think it does not add 
> much]
> > 
> > >For the 'average' user, the EFS files are just going to be another 
> > >proprietary binary file format, they are not going to care that it is a 
> > 
> > Propiertary, maybe. But I guess the specs will not be hidden like others, so
> > the problem is minimum (maximum now, but let pass some time and it will be
> > minimum). And always you can save in a different format. ;]
> > 
> 
> I agree completely, what I meant is that the "average" user isn't going 
> to care much about what is inside the file. The rest of us, however, 
> will be able to do lots of neat things with it.
> 
> > 
> > >filesystem within a file. Someone will eventually want to send an email 
> > >with their spiffy new spreadsheet that shows the question to the answer 
> > >to the universe, life, and everything as an attachment. A directory 
> > >would make this very frustrating for this user as this user is just 
> > >going to select the "document", send the email, and get a response from 
> > >the recipient that the email contained nothing.
> > 
> > 1 document <-> 1 file is the way some OS handle this. NeXT used a different
> > method for applications, but it was build in the system, GNOME can not force 
> it.
> > 
> 
> Yes, GNOME will not be able to enforce making a directory look like a 
> single document outside GNOME, as GNOME has no control over the OS at 
> large, therein lies the problem with using a directory structure as one 
> document.
> 
> > 
> > >EFS has advantages over the other proposed formats in that it will be 
> > >time efficient in saving/loading, but filesystems in a file have the 
> > >disadvantage of occasionally have ununsed spots where things have been 
> > >replaced but the replacement wouldn't fit, disks are big though, and 
> > 
> > EFS defrag tool? EFS auto defrag / anti frag?
> > 
> 
> That would be very nice, another, perhaps additional, approach is to 
> keep track of fragmentation and when it reaches a certain point 
> automatically "defrag" on a write of the document. Perhaps the defrag is 
> simply to rewrite the whole document at that point without the holes, 
> maybe a lot faster if there is a lot of fragmentation.
> 
> > >most of these dead spots can be minimized. I like the idea of providing 
> > >utilities to extract the data, and yes, if we used the zip format, this 
> > 
> > That is a must, IMHO, there must be a way to extract and create EFS file
> > like you create ISO or EXT2 images. A kernel module to mount EFS (project of
> > the week? /me ducks and runs) could be a idea for the future, and I guess
> > that if the EFS is used we will see the patch for at least Linux and *BSD
> > kernels. And maybe even tools for Windows like the ones for EXT2.
> > 
> 
> This was suggested as an option before, and it would be reasonably easy 
> to do.
> 
> > 
> > >would be done for us, but zip does not handle dead space as efficiently 
> > >as possible, in fact not really at all, and I'm not really sure this 
> > >tasks requires the compression, or would even really provide sufficient 
> > >benifit from having the compression given that one of the objectives is 
> > >to provide a mechanism to tie images and other pre-compressed things to 
> > >documents.
> > 
> > IMHO the best is to use a file that behaves as a filesystem and provide
> > esf2dir and dir2efs, so you can extract and build, just that. No compression
> > at all, except the provided by the formats that go inside EFS file (letter
> > with PNG logo, ie). If you want compression use .efs.bz2 or similar aproach,
> > like Gimp's XCF way. Or compress the docs inside, so a EFS file has .tga.bz2
> > inside. Keep things easy, reuse tools if you can.
> > 
> 
> I like that, compressing the textual documents that are put into the EFS 
> before they are put there. This accomplishes what zip does but only does 
> it on the most compressible thing, text.
> 
> > 
> > I do not see what is all the problem with EFS. IMHO, library + tools +
> > kernel mod and you have all basic problems solved, just code it (work in
> > progress, no?). I hope this idea will be used, I have been using Blender and
> > the file format is similar, thus allowing imports and links from one file to
> > another.
> > 
> 
> You are talking to a bunch of engineers, therein lies the heart of the 
> problem, each has their own, usually strongly held, ideas what a perfect 
> system would be like. ;-) I'm just curious to see what comes of this 
> discussion.
> 
> > 
> > What is more I hope the EFS would be used to put Unix like FS inside a file
> > that grows and shrinks as needed, so you can use it anywhere. Imagine the
> > possibilities. It sounds like "make your ISO or EXT2 FS in a file" but newer
> > & better (auto resize as space is requested / released). Why do not let the
> > coders implement EFS? Let them and then we test it. :]
> > 
> 
> It was suggested earlier in this discussion to have those in favor of 
> EFS prototype, test and benchmark that, those that wanted the zip format 
> to do the same, and those that wanted the directory structure to do the 
> same. The problem with that is I have a feeling that there are those out 
> there that would like to see some end result sometime this decade :P I'm 
> pretty sure someone is off doing one of these already as the rest of us 
> discuss it.
> 
> TTFN
> MikeB
> 
> Application development is a race between software engineers who
> try to create fool proof programs and the universe which is trying to
> develop superior fools.
> 	
> 	So far, the universe is winning.
> 	Let's not give it any help...
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>