Jamie Lokier wrote:
>Note that file-as-directory doesn't imply that you can store just
>anything into those directories.
>
>Is it a problem to decree that "file data MUST NOT be stored in a
>metadata directory; only non-essential metadata and data computed from
>the file data may be stored"?
>
>
That's exactly what folks seem to lost in this debate.
We (developers) want to have files as dirs to:
* be able to extract/modify file part on fly. For instance, simple .iso
file, without need to mount it over loop (btw, if someone is going to
redesign VFS, can we handle that kinda case too please?), .tar, or
unzipped (kernel can handle zips) "streams". File is a stream, why
shouldn't I have a chance to grab a stream out of archive/image than ?
* be able to store metadata, that doesn't matter on copy, and even
should not be copied sometimes. Things like thumbnails, metainformation
(used for search). All of these extracted from acctual file (either by
VFS 'plugins', or by userspace application), and saved there so that it
can be used later on. So we save some time on extracting it.
--
GJ
On Fri, Sep 03, 2004 at 06:36:41AM +0200, Grzegorz Ja??kiewicz wrote:
> Jamie Lokier wrote:
>
> >Is it a problem to decree that "file data MUST NOT be stored in a
> >metadata directory; only non-essential metadata and data computed from
> >the file data may be stored"?
>
> That's exactly what folks seem to lost in this debate.
And that's not even the most important part: How would you educate all
the developers _not_ on this list: application developers? I think this
is just a disaster waiting for us to occur.
> * be able to extract/modify file part on fly.
> * be able to store metadata, that doesn't matter on copy
those may be orthogonal.
--
Frank