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

Meta files for files without new interfaces

Niels Möller wrote:

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:


On Sat, Jan 19, 2002 at 11:35:46AM -0800, Justin  Langer wrote:

What can be its possible application?

You could access the web with all tools, including your shell.  Instead
running wget, you could just try to use cp, for example.

This httpfs discussion made me think some more about one of my
wouldn't-it-be-nice-to-have wishes for the Hurd. Sorry to bore you
with it again, but I can't help myself. ;-) You have been warned...

I want property lists on inodes. Even if it isn't supported at all by
major filesystems like ext2, it would still be very good to have a
standard interface to properties for filesystems where it makes sense.
Some obvious applications:

> [snip]

Adding properties is a simple matter of adding a few more rpc calls to
the file interface.

What would be even cooler is to be able to provide a list of
properties when *opening* a file. The filesystem would then find data
matching the properties. For instance, the httpfs translator could put
such properties into forms variables and/or cookies. A versioning
filesystem could recognize a version number-property. A cvs filesystem
could recognize a branch tag property.

As a way to avoid new interfaces for dealing with properties, we can use
the empty file name "". So `cat index.html//mime/content-type' would print `text/html'. There can be a convention after the two slashes to reside a package name and after that whatever metainfo has the package. This way it is possible to preserve metainfo when backuping to a simple media and restoring the files will restore the metainfo as it was in the translator! (There are many details, of course.) Touching `cp' and similar commands to support this will cost little.

Actually this metainfo will turn to virtual directory of files and directories that can be touched with `bash', for example. This metadirectory can be used to control translators, not only to query them. To avoid conflicts it would be best to reserve the first level for package names. (I mean Debian package, but the idea can be generalized.)

Ognyan Kulev <ogi@fmi.uni-sofia.bg>, "\"Programmer\""

Reply to: