Re: Request: Test suite for EFS.






On Thu, 17 Feb 2000, Kent Schumacher wrote:

> bob@thestuff.net wrote:
> 
> > First, a few questions. What file system does EFS use? Is it something
> >that any unix that supports mounting a file vea loop back can mount? Is it
> > a standard file system? If not, being able to read the file by any non
> > gnome app would be difficult to implement. Also, why EFS? Can gnome-vfs
> > not do what you want? No one commented on the use of tar as the file
> > system to maintain portability. What do you guys think of it?
> >
> 
> Regarding tar files.
> 
> Tar has at least 3 shortcomings.
> 
> 1) There isn't an index to allow quickly moving to a given data item.
> 2) There isn't any way to insert a data-element that has grown without
>     re-writing the whole file
> 3) There isn't any way to remove or shrink a data-element without rewriting
>     the whole file.
> 
> It's interesting to note that points 2 and 3 are problems that are common to any sort of
> storage management system, be it malloc, a filesystem, or a data-base.

Why don't we just store compound documents as directories? The files
in this directory would be the individual components of this document.
If they themselves were compound documents they would, of course, be
subdirectories rather than files. 


example.gnumeric
   |
   |
   |- .bonobo - standard file with compound document structure
   |
   |- sheet1.xml
   |
   |- component.gwp  - embedded word processor document with embedded graphs
   |     |
   |     |- .bonobo - structure of embedded document
   |     |
   |     |- graph1.png
   |     |
   |     |- graph2.png
   |     |
   |     |- text1.xml
   |
   |- sheet2.xml


This wouldn't be too confusing if file managers were programmed to
check for the existence of the .bonobo file and treat directories
containing such files in a special way.

Alternatively we may be able to use one of the currently unused
attributes (from lsattr, chattr etc) to signify that the
directory is a compound document; though this would not be portable
to all file systems.

We could always offer the option of storing the document as a (zipped)
tar archive, but this would lose the search capabilities that some
previous poster found desirable. In this case I would envisage untarring
the file when it is opened and re-tarring it when the document is finally
closed and unloaded from whatever application is being used to manipulate
it.

Norman



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]