Well, resource forks are treated like files in CAP. There's also Apple Double.
> base file? No. Can MacOS attributes be symbolic linked across files to
> save space and be more generic? No. Can MacOS resource fork attributes be
> different things to different users in a multiuser environment? No.
> Directories are all 'Yes' to those questions, and they are extremely fast
> with 2.2. Whats your problem with directories?
It was probably an overreaction to certain folks that I'm around that
don't really have an appreciation of other OSes ideas. Unix/Posix isn't
everything you know and some of the conventions in Unix are pretty damn
arcane.
I'd be irriated if folks were resistant to this kind of stuff without
questioning typical OS conventions.
[Open/NeXT]Step uses directories for this kind of stuff and it's an
acceptable work around. Mac OS X probably does the same thing since
it's mostly OpenStep.
And some of these particular notions are pretty cool under various OSes
that.
It would be nice to have something slicker.
BeOS has a minimal "attributes" API and it's pretty simple to implement.
Adding:
fs_[ read,
write,
rewind,
open,
close,
stat,
remove,
rename ]_attribute ( int fd, ......);
Isn't going to break Linux if it's encapsulated in a module of some sort.
The NFS folks will just have to be comfortable about this API breaking
and have the GUI environment work around having a technical subset. That's
the application programmer problem. It'll work great for local disks with
stuff like GNOME if someone would clue into it.
Maybe it's a bad idea and inappropriate for Linux/Unix. It seems that
preserving per file ACL information is an equal problem.
bill
> -- mingo
-
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/