On Sun, 13 Aug 2000, Alan Cox wrote:
>
> 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.
See earlier emails on why this is unusable for NTFS due to hardlink
capabilities.
> > 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
Note that if fd_open is dangerous for security, then so is "fchdir()".
Because you can emulate fd_open() with fchdir()+regular open. Slowly, but
still.
> > Maybe in the future, if we support resource forks on other filesystems
>
> We already do. Have done since 1.3.something.
No.
We have had ad-hoc support for some special cases.
Linux hasn't supported them as a notion.
> hfs works fine. This is a debate about an existing solved non problem.
Alan, do you really mean to say that every filesystem that has resource
forks shoul dsolve the problem over and over again, and in different
manners?
It's already been made clear that the HFS solutions is unacceptable for
NTFS.
In contrast, the NTFS solution _would_ be acceptable for HFS.
Think about it. Which one is the better solution?
Linus
-
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