> The point is to be able to access resource forks in a way that is
> compatible with UNIX filesystem semantics.
We already do that for Apple HFS. We create a fake directory for each dir
which is called .AppleDouble and contains the resource fork. It works pretty
well on the whole. rename() has some suprises and a generic unix cp command
will lose the resource fork but it works ok.
> filesystems. Sane and usable. Things like "fd_open()" make sense even
> without resource forks - it's kind of a private extension of the notion of
> "current working directory", after all.
fd_open is interestingly dangerous for security unless carefully considered.
But yes it should be sat down and thought through
> Maybe in the future, if we support resource forks on other filesystems
We already do. Have done since 1.3.something.
> This is a practical matter of "how do we sanely export non-UNIX semantics
> of other systems filesystems to UNIX programs".
hfs works fine. This is a debate about an existing solved non problem. Providing
you don't want to keep the illusion intact at all levels (eg cp copying all
the forks) then its not a problem.
The appletalk file server even knows about this so that it can put the forks
back together for a macos client.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:30 EST