Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!garnet.bmr.gov.au!como.dpie.gov.au!news.gan.net.au!act.news.telstra.net!vic.news.telstra.net!news.mira.net.au!harbinger.cc.monash.edu.au!news.bhp.com.au!mel.dit.csiro.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!usenet.ins.cwru.edu!gatech!news.mathworks.com!uhog.mit.edu!news.mtholyoke.edu!nntp.et.byu.edu!news.caldera.com!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Subject: Re: Ideal filesystem
Date: 23 Mar 1996 08:22:47 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 63
Message-ID: <4j0ccn$ftv@park.uvsc.edu>
References: <4gejrb$ogj@floyd.sw.oz.au> <3140C968.20699696@netcom.com> <4ia7im$i4m@usenet.srv.cis.pitt.edu> <4if9gb$4kh@park.uvsc.edu> <4iibd2$ng@EARTH.baylor.edu> <4ir7tc$5uf@park.uvsc.edu> <31530CC6.266C03EF@ids2.idsonline.com>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20177 comp.unix.bsd.freebsd.misc:16167
Eric Vought <adfh@ids2.idsonline.com> wrote:
] > ] >2) Desktop position information for an icon
] > ]
] > ] This is not good for a multi-user environment. No two users will want
] > ] icons in the same place.
] >
] > This is not a good argument. One could just as easily have an
] > attribute per user.
]
] This *is* a good argument. Per-user attributes go in user owned space.
For instance... the user owned space that a user may attach to
any file on the system to which he has access and which on he
(or root) may later access? 8-).
The ideas are not mutually exclusive.
] Per file attributes go in system owned space. Put user information in
] the user's home directory, not attached to a file. Attaching per-user
] attributes to files causes problems with deleting or editing user
] accounts.
Only if you do it wrong.
] In order to get rid of user "joe", the system now has to scan
] all files for per-user information and delete those entries pertaining
] to joe. This problem already exists to some extent with files that are
] owned by that user, but these are often limited to the user's home
] directory, a spool file, and possibly a public sticky directory. Your
] suggestion makes the mess more widespread and more complicated.
Why can't you ask the question "will all the objects owned by
Joe please identify themselves?"... after all, indexing is
implementation defined, and we're talking about a new implementation.
] Icon information is also potentially per-user. For instance, take a text
] editor, "joe". Joe is a text based, non-graphical editor. Some people
] may very well want to map it to an icon. Others, particularly those who
] don't have an X connection, will not. Additionally, even X-only programs
] may have problems. I may not like so-and-so's choice of an icon and may
] want to use my own.
I was thinking "icon identity", not "icon bitmap/pixmap". That
is, an identifier that could be looked up per user (and then
taken from the default -- maybe in an EA -- if the lookup fails).
] A better solution would be to use a resource file to specify the icon.
] On installation, the program can use its default option, but this can be
] overidden in user space.
I don't understand why a resource file for an application must
have a seperate entry in the file system name space. An EA,
after all, is a sub-namespace that is *not* exported into the
general file system namespace.
After that, a file is a file is a file...
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.