Re: Resource forks and such
Fred Reimer (Fred.Reimer@bellsouth.net)
Sat, 10 Jul 1999 02:16:21 -0400
On Fri, 09 Jul 1999, david parsons wrote:
> In article <linux.kernel.199907082146.RAA03078@speaker.kf8nh.apk.net>,
> <allbery@kf8nh.apk.net> wrote:
> >On 8 Jul, Jens-Uwe Mager wrote:
> >+-----
> >| On Tue, 6 Jul 1999 22:22:39 GMT, allbery@kf8nh.apk.net
> >| <allbery@kf8nh.apk.net> wrote:
> >| >On 6 Jul, Jason Gunthorpe wrote:
> >| >| I haven't seen anyone mention this yet, but on OS/2 these 'albods' (called
> >| >| EAs) were not used for compound documents but they were used to store
> >| >| non-critical 'metadata' about files. With OS/2 you could give a different
> >| >
> >| >That said, the problem with storing the metadata with the file is that
> >| >on a multiuser OS different people may want different associations,
> >| >different icons, etc.for the same file. So it has to be stored per
> >| >user, not per file. Also, how do you assign icons to files which are
> >|
> >| I think not, the way document types work these should not be changed on a per
> >| user basis. For example, if you would store a mime type with each document,
> >| then a GIF image will get image/gif and as long as the file is not rewritten
> >| to contain something else its meta data should definitely be the same.
> >+--->8
> >
> >The example given (which I clipped; I should have left it) was an icon,
> >which is indeed stored in an EA on OS/2. That's the sort of thing that
> >has no business being stored with the file on Unix (including Linux).
>
> Applications would like to have defaults; if the user doesn't specify
> the icon of their dreams, you need to have SOMETHING to fall back on
> unless you're fond on making the users find the invisible icon.
>
>
> >NB: OS/2 will also get an icon for an executable file from a .ICO file
> >with the same root-name in the same directory. That one would work
> >fairly well on Linux.
>
> So have the default icon be in {self}/ICO, so if the UI can't find
> an icon anywhere else it will look there; this way you don't drop
> the icon on the floor when you move or rename the application.
I almost sent this comment before, but withheld because I wasn't sure I
knew what I was talking about. I'm sure someone will correct me if I'm
wrong.
Wasn't there some discussion a while back when capabilities were being
discussed about putting the capabilities in the ELF header with some
tag or something that is supposed to be ignored if the app/loader does
not know about it? I believe the arguments against that had to do with
security and how one would ensure someone couldn't modify the
executable to gain greater capabilities. There may have also been some
discussion about backwards compatabilities and if it would work on
"old" systems.
Well, capabilities may have these problems but Icons certainly don't.
There's no security attached to icons, so if someone mucks with it who
give a hoot. We also don't need to worry about backwards
compatabilitiy because there CERTAINLY wasn't and of this resource fork
stuff in older version of Linux so the apps that may be written
to use them couldn't run on old systems anyway.
Is there any reason that this ELF header tag thigamajig would not work
for capabilities? I don't really know what I'm talking about (and
admit it) but it may be something that people could agree on.
Let me know if I'm out of my mind and should just get some sleep.
Fred
-
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/