Re: The argument for fs assistance in handling archives

Christian Mayrhuber
2004-09-02T14:38:30Z

On Thursday 02 September 2004 12:02, Spam wrote:
> > As I say I like the idea, but I can't see anyway of implementing it in
> > a way that is useful without first putting considerable effort into at
> > least the VFS if not all the actual fs drivers.
>
> Indeed. It is important that something like this gets implemented as
> a transparent way as possible. If it could be done in a general way
> so other filesystems like ext3/4 can eventually support it then that
> would be wonderful. I do not, however, think that we should block it
> in reiser4 because no other filesystems support it.

What about extending the namespace with leading ".." and "...".

In Unix names starting with a "." already have the meaning of being a
hidden/config entry.

A name starting ".." means streams/metainformation, etc. something belonging
to the file/directory that should get backed up, copied, etc.
There could be a "..streams", "..metas" or a "..acl" entry.

If it starts with "..." it means some system specific information, like the
name of the hash algorithm used for the current directory. It's basically
information that is not portable and not required by applications, like
"...fsplugins".

There is still the big problem of how to copy files with their associated
streams or meta information onto a standard unix filesystem as the
file/directory duality cannot be expressed. (It's forbidden to have
a directory + file with the same name in the same directory)
Maybe copy could create something like a ".#filename" directory for this kind
of information if the advanced features are not supported on the target
filesystem. This is neither nice nor clean, but at least you don't loose
information. I do not suggest that the kernel should simulate the advanced
features with ".#filename" directories, it's more a backup/restore thing
that could work if it's written down properly.

--
lg, Chris