Re: The argument for fs assistance in handling archives

[Spam <spam@tnonline.net>]

  

>> Depends on how the forks eventually get implemented.
>> With the file-as-directory concept, all you need is to
>> look at the file's directory part to see what is there.  (The forks,
>> implemented as files in a subdirectory.)  It is done the same way
>> as for an ordinary directory, so nothing "new".
>> 
> This still doesn't solve the problem of how we distinguish between a
> multi-fork file
> and a directory, for those old programs(ie. almost all that currently
> exist), to be able to access meaningful data we would need to either
> return just the primary fork, a serialized version of all forks in the
> file, or make the file look more or less identical to a directory.

  Well. wasn't the idea that unless programs specifically tried to
  open the file-as-dir as a directory it would look like a file?

  ls -F would show it as file. Or have I understood wrong?

> The first option could cause problems when transfering files between
> different filesystems,

  The meta-data should be deleted if it the file is copied or moved to
  a medium that doesn't support it. However a _warning_ may be shown
  to the user if there is risk to loose data.

  I do not think we should not implement something like this because
  most other filesystems in Linux doesn't support it. Think of other
  limitations there is in various ones. Large file support. Limited
  amount of files, length of file names, etc.

> the second results in programs getting metadata they can't handle, and
> the third option results in few of the advantages over, well,
> directories...  And even those applications that could handle the fork
> information nicely would need to fs type to find out whether they were
> handling a directory or a multi-forked file...

  No, if an application supported the file-as-dir then it could simply
  try to open the file as a directory. It would fail on systems that
  didn't support it.

  The meta-data and file streams would be seen as ordinary files. If
  applications support the contents or not isn't really relevant, is
  it?.

> 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.

  ~S

> --Oliver Hunt