Default icon, certainly. Users could override that, but that is not
appropriate to store with/on/in the file itself in a multiuser setting.
| The question then becomes whether to also have per-file preference attributes
| in every file a user touches, or to have some kind of database per user with
| all their file preferences in it (with all the associated difficulties of
| keeping it in sync, identifying files, etc, etc).
+--->8
Another problem with the former is that it's highly questionable whether a
user should be allowed to affect metadata "attached" (in some sense) to a
file to which they don't have write access. This is especially important if
a kernel-based metadata solution is used: do we really want the permissions
on the metadata fork to be different from the data fork? I don't think so.
And with a separate-but-nearby metadata model (e.g. dot-directories) you
would have to grant world write permission to the directory in which the
metadata are stored; this also doesn't appeal (think /etc/passwd). But
denying the user the ability to store metadata about the file also seems
wrong.
A per-user metadata database has its problems, yes, but it doesn't raise
potential security issues.
| Are there any multiuser systems which address the problems of per-user
| preference info stored in file attributes?
+--->8
I think you'd have to ask the NeXTSteppers or BeOSers or maybe someone who's
seen what Mac OS X is doing. NT went with the database approach, of course
(the registry... and look what kind of problems that causes!),
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering KF8NH carnegie mellon university
- 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/