Theodore Y. Ts'o wrote:
snip snip
>
> Creating a kernel API which works by storing the file metadata inside a
> non-standard, Linux-only filesystem *would* be encouraging application
> programmers to write non-portable programs, and that's what I object to.
>
> You were arguing that we should avoid creating a non-standard API,
> and I submit that you yourself do not believe this; You are,
> afterall, creating a new facility, these ext2 ACLs, right? Aren't
> you going to create a new API for it? Why, in principle, does
> your argument make sense for "storing user metadata" but not for
> your ACLs?
>
> Actually, there already is a proposed POSIX standard interface which for
> setting and reading out access control lists. It is implemented on a
> number of other commercial operating systems, such as Trusted HP-UX and
> Trusted Solaris. (Yes, you have to pay extra if you want ACL support
> --- although these systems also have a number of other extra features
> beyond just ACL support.)
>
> My concern is not so much with the non-standard API, though, but
> encouraging application writers to write non-portable programs that only
> work under Linux.
>
> And of course, if you've ever had to deal with moving Macintosh
> multi-fork files across the Internet (where if you forget to binhex the
> file first, you'll end up trashing it because you'll lose the resource
> fork), you'll understand my additional concerns about encouraging
> application writers to use this functionality at all, whether or not
> whether it's done in the filesystem or via a user-mode shared library
> API.
Now now. The big thing is to really not depend on the presence/support of
metadata. Here it goes. You have file and its metadata. You transfer over net
using metadata-unaware program/system. Metadata lost. Application opens file.
No problem. User edits file, perhaps. User hits save. Application realizes
there is no metadata. Application writes metadata. No problem.
Next scenario. User downloads file with metadata-aware program. Metadata
transfered. No problem.
Next scenario: User downloads file from non-metadata-supporting computer with
metadata-aware program. Program discovers other computer does not have
metadata, so it doesn't worry about it. Created as above when saved by some
app.
Last: User downloads file from aware computer to unaware. Metadata is lost. No
problem.
>
>
> It makes sense for information which the desktop stores for its purposes
> (such as icon management); but it should be the case that you don't lose
> anything vital if the resource fork gets dropped after it got copied via
> some application or protocol that doesn't understand the non-standard
> resource fork.
What is so crucial?
> In practice, this means that most of the time
> application writers *shouldn't* be trying to use resource forks.
> Desktop systems, sure; but application data should be stored in the main
> data fork, since anything in the resource fork may disappear
> unexpectedly.
So it disappears. Anything you rely on you don't put there.
>
>
> - Ted
>
> -
> 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/faq.html
-
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/faq.html