Resource forks

Resource forks

Post by kdp0.. » Sat, 17 May 1997 04:00:00




> One big pain-in-the-ass about Unix/X is the way you have config
> files scattered all over the place.  One thing that is nice about
> the Macintosh is its use of resource forks.  The resource fork
> of a file holds its icon, creator, file type, configuration info,
> and anything else that the application or file needs.  To change
> an application's icon, you just edit its resource fork.  

They are implemented in linux: they're called directories.

-A.

 
 
 

Resource forks

Post by Albert D. Cahal » Sat, 17 May 1997 04:00:00




>> One big pain-in-the-ass about Unix/X is the way you have config
>> files scattered all over the place.  One thing that is nice about
>> the Macintosh is its use of resource forks.  The resource fork
>> of a file holds its icon, creator, file type, configuration info,
>> and anything else that the application or file needs.  To change
>> an application's icon, you just edit its resource fork.  

> They are implemented in linux: they're called directories.

Arrrgh! That is not even close. Not that I want resource forks,
but they can do many things that directories can not do.
For example, "cat some_directory | uuencode foo" won't work.

Now, some better solutions:

Quote:>> The resource fork of a file holds its icon,

For executables, an ELF section would do the job.
(executables you can run but not read are the exception)
Can we standardize on a format? I'd guess a predefined
palette of "Netscape + VGA + transparent" is good.
Require these: 16x16 32x32 64x64 128x128.

Quote:>> creator,

Not very useful.

Quote:>> file type,

Ouch. Mostly, we are stuck with extensions and magic.
If a standard document file format is ever done
(like OpenDoc bento, OLE .doc, or the javabeans thing)
then that could hold quite a bit of extra information.

Quote:>> configuration info,

Not inside the app! People can share executables
and put them on read-only media. The current solution
may be bad, but abusing forks that way is worse.

Unix does have a problem here, but there is nobody
who can fix the problem. Any fix would be incompatible
with existing code and stubborn users. Great ideas
are often not accepted because they are incompatible.
Hey, I found something good about Microsoft! Wow.
(they are limited by 3rd-party software though)

Quote:>> and anything else that the application or file needs.

Pro: Everything is together. You can drag-and-drop the
whole program together.

Con: Bloat, either "fat" executables or duplication of
data for each platform.
--
--
Albert Cahalan <acahalan at cs.uml.edu> My address may be mangled to
avoid junk email. Please check it if you wish to respond to a news post.

 
 
 

Resource forks

Post by Larry Pyea » Sat, 17 May 1997 04:00:00


One big pain-in-the-ass about Unix/X is the way you have config
files scattered all over the place.  One thing that is nice about
the Macintosh is its use of resource forks.  The resource fork
of a file holds its icon, creator, file type, configuration info,
and anything else that the application or file needs.  To change
an application's icon, you just edit its resource fork.  

Is it possible to implement resource forks under Unix?  I envision
a file manager that just looks at a file's resource fork to determine
what kind of file it is, what its icon looks like, etc.  The resource
fork could be used by the application to store its state and
configuration information without using all those app-defaults and
other config files.  Current apps need not use their resource forks,
but could be converted to this method over time.  I know it would
take a lot of work to get it going, but it could result in a
system that has the power of Unix and the ease of use of a Mac.
Is it possible?

--
Larry D. Pyeatt                     All standard disclaimers apply.

http://www.cs.colostate.edu/~pyeatt

 
 
 

Resource forks

Post by Mark Ha » Sun, 18 May 1997 04:00:00


: >> One big pain-in-the-ass about Unix/X is the way you have config
: >> files scattered all over the place.  One thing that is nice about
: >> the Macintosh is its use of resource forks.  The resource fork

there's no accounting for taste.  I'll stick to Unix.

: >> of a file holds its icon, creator, file type, configuration info,
: >> and anything else that the application or file needs.  To change
: >> an application's icon, you just edit its resource fork.  
: >
: > They are implemented in linux: they're called directories.

or simply auxiliary files.  if your binary "netscape" has an icon,
put it in a file called "netscape.icon".  since you're using a
macophilic finder interface, tell it not to display aux files.
I'm aware that on most Unix FSs, this would consume one inode and
at least one data block or fragment, but that's purely an implementation
detail.

: For example, "cat some_directory | uuencode foo" won't work.

tar. serializing a structured object requires some kind of format.

: >> file type,
: Ouch. Mostly, we are stuck with extensions and magic.

which is The Right Choice, as long as you don't go as far as to
mandate a complete object structuring system (and concomitant language).

regards, mark hahn.
--

                                        http://neurocog.lrdc.pitt.edu/~hahn/

 
 
 

Resource forks

Post by kdp0.. » Sun, 18 May 1997 04:00:00





> >> One big pain-in-the-ass about Unix/X is the way you have config
> >> files scattered all over the place.  One thing that is nice about
> >> the Macintosh is its use of resource forks.  The resource fork
> >> of a file holds its icon, creator, file type, configuration info,
> >> and anything else that the application or file needs.  To change
> >> an application's icon, you just edit its resource fork.  

> > They are implemented in linux: they're called directories.

> Arrrgh! That is not even close. Not that I want resource forks,
> but they can do many things that directories can not do.
> For example, "cat some_directory | uuencode foo" won't work.

It won't work neither with a file with resource forks (because uuencode
doesn't know anything about forks and cat can't encode them into a stream
anyway). It would be circa the same work to teach uuencode/cat about
directories (the "directory cat" is called tar BTW ;) as to teach them
about forks.

For example see the NextStep platform. They don't have files as executables
but use a directory with many files in it. Then you just run the directory.

-A

 
 
 

Resource forks

Post by Larry Pyea » Sun, 18 May 1997 04:00:00




> >Is it possible to implement resource forks under Unix?

> In UNIX, the system is being used by multiple users, often at
> the same time. Storing user specific information like paths,
> window positions or user defaults in the file is not possible,
> because you don't have write permission to this file in a
> correctly configured system.

You don't need write permission.  You can create a link and
store your personal info in the link's resource fork.  The file
manager program can just read the link's resource data.  This
is not much different in concept from the current approach which uses
.Xdefaults (or in my case ~/app-defaults).  

Quote:> The central place for storage of user specific data in UNIX is
> the users home directory. Applications have to store their
> state information and defaults there or fail.

Right.  That's why resource forks would be very useful.  Currently
you have to manually configure all those .cshrc, .login, .Xdefaults,
etc.  Lots of Unix newbies are not up to that.  I am trying to
come up with a solution for newbies, not for you and me.

(snip)

Thanks for the explaination of NextStep.  I had wondered how they
dealt with it.  I am thinking of something a bit simpler, and
(possibly) more elegant than the directory approach, from the
user's perspective.  What I have in mind will require changes to
the filesystem itself.

 
 
 

Resource forks

Post by David Giv » Sun, 18 May 1997 04:00:00




>One big pain-in-the-ass about Unix/X is the way you have config
>files scattered all over the place.  One thing that is nice about
>the Macintosh is its use of resource forks.  The resource fork
>of a file holds its icon, creator, file type, configuration info,
>and anything else that the application or file needs.  To change
>an application's icon, you just edit its resource fork.  

>Is it possible to implement resource forks under Unix?  I envision

[...]

Otherwise known as extended attributes. Sure, easily done (doesn't ext2
have support for extended attributes on files?), and yes, they would be
very useful. Unfortunately... Unix doesn't use EA's. If you implemented
EA's, then it's not Unix. Since the biggest strength of Unix is the
compatability (the same program is trivially ported between platforms),
there's no point whatsoever in doing this.

A more portable way is to use hidden files. Check out how xv stores image
thumbnails as an example.

--
------------------- http://www-hons-cs.cs.st-and.ac.uk/~dg --------------------
   If you're up against someone more intelligent than you are, do something
    totally insane and let him think himself to death.  --- Pyanfar Chanur
---------------- Sun-Earther David Daton Given of Lochcarron ------------------

 
 
 

Resource forks

Post by Remco Treffko » Sun, 18 May 1997 04:00:00



Quote:> For executables, an ELF section would do the job.
> (executables you can run but not read are the exception)
> Can we standardize on a format? I'd guess a predefined
> palette of "Netscape + VGA + transparent" is good.
> Require these: 16x16 32x32 64x64 128x128.

Please tell me a reliable way an application can find the file it is
started from.

This request seems innocent, but it will waste alot of bandwidth!

--
Remco Treffkorn (RT445)
HAM DC2XT


 
 
 

Resource forks

Post by Kristian K?hnto » Sun, 18 May 1997 04:00:00



>Is it possible to implement resource forks under Unix?

Yes it is possible (Nextstep has done it, see below), but it
would be a most stupid thing to do to get the jobs done you
mentioned.

In UNIX, the system is being used by multiple users, often at
the same time. Storing user specific information like paths,
window positions or user defaults in the file is not possible,
because you don't have write permission to this file in a
correctly configured system. Often you don't even have write
permission to the entire file system where the application
resides, because this file system is a read-only network mount
with replicated servers for fault tolerance.

The central place for storage of user specific data in UNIX is
the users home directory. Applications have to store their
state information and defaults there or fail.

Ressource forks have been done in Nextstep. In Nextstep, an
application consists of one binary (with code sections for
multiple architectures) and tons of ressources (with different
ressource sections for different locales) and additional data
losely attached to the application (example files, help files
and so on). The ressources of some application can be amended
by the system administrator (or the application owner) by
placing additional code ressources in the application. This is
possible, because in Nextstep files are not two-ended, single
level as on a Mac, but n-ended, n-level. That is, in Nextstep,
you can have an arbitrary number of forks and each fork can in
turn have an arbitrary number of subforks.

Physically this is implemented in Nextstep as directories. An
application "MyApp" is a directory named "MyApp.dir" with a
binary file "MyApp" in it. Additionally the MyApp.dir may
contain any number of "LanguageName.lproj" directories, which
in turn contain the localized ressources of an application.
Non-localizeable ressources and default ressources are stored
directly in the MyApp.dir, though. The directory owner may
place additional code in "MyBundle.bundle" directories within
the application directory. These bundles are loaded if the
application knows about Nextstep bundles and can be extended.

In Nextstep, this directory is presented to the user as an
opaque icon (with custom graphics, not with folder graphics) in
WorkspaceManager. Doubleclicking the application icon launches
the binary file within the application folder, moving the icon
around copies the entire directory hierarchy.

Still, user specific application defaults are stored in the
Nextstep aequivalent of a registry in the users home directory.

Kristian
--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897

 
 
 

Resource forks

Post by Doug DeJuli » Mon, 19 May 1997 04:00:00




>Thanks for the explaination of NextStep.  I had wondered how they
>dealt with it.  I am thinking of something a bit simpler, and
>(possibly) more elegant than the directory approach, from the
>user's perspective.  What I have in mind will require changes to
>the filesystem itself.

I have a hard time seeing how you can come up with something simpler
and more elegant than what NeXTstep does -- from a user's perspective.

The typical NeXTstep user is never made aware that some of their icons
are immplemented at a low level as "files" (eg. a plain ASCII text
file) and others are implemented at a low level as "directories" (eg.
an RTF file with an embedded picture).  The UI doesn't really provide
them with any way to distinguish between the two, unless they start
using Unix-geek tricks (like starting a shell, which most users I've
worked with never do).

Similarly, on a Macintosh, the typical user is never made aware that
some icons have resource forks (eg. an RTF file with an embedded
picture) while other files are just data forks (eg. a plain ASCII text
file).  The UI doesn't really provide them with any way to distinguish
between the two, unless they start using Macintosh-geek tricks (like
starting ResEdit, which most users I've worked with never do).

From a *user's* perspective, there just isn't much difference between
the two.  It's the programmers that see the difference, and that
difference could be hidden from them by a compatability library.

Adding resource forks would not be simple -- you'd either need new
system calls or ioctls to access them, and those would be heinous to
use until a library of wrappers was written.  So, just write the same
library over existing system calls, using directories, and be done
with it.  You'll end up with something that can be used under Linux or
Solaris or Rhapsody or OSF/1.

--
Doug DeJulio

 
 
 

Resource forks

Post by Kristian K?hnto » Mon, 19 May 1997 04:00:00



>Please tell me a reliable way an application can find the file it is
>started from.

Since we are in a linux development groups: open
/proc/self/exe, there it is.

Of course, applications can't open their executeable in general,
because it is root.root or bin.bin and 111.

Kristian
--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897

 
 
 

Resource forks

Post by Kristian K?hnto » Mon, 19 May 1997 04:00:00



>Thanks for the explaination of NextStep.  I had wondered how they
>dealt with it.  I am thinking of something a bit simpler, and
>(possibly) more elegant than the directory approach, from the
>user's perspective.

Actually, the Nextstep approach to the problem is quite
elegant, because those Nextstep users who don't use Unix
terminals never see the App as a directory. Only when you
specifically request the FileManager to open an Icon as a
directory, you would see the contents of this particular
Application-Directory. Which is in turn an elegant solution,
too, because you don't need a special ressource editor to
access an applications ressources - you use the normal
FileManager interface to add, remove or rename ressources and
you use the normal Unix backup and file manipulation utilities
to save and restore Nextstep applications, share them over NFS
or otherwise manipulate them.

Apple-style ressources are a form of crippled "file interpreted
as a directory tree". Cripples, because you can't have
ressource forks having ressource forks and you can't have
n-braches, only 2-branches. If you generalized this approach,
you would have a full fledged "file interpreted as a directory
tree".

Of course, updating the file with ressources becomes a problem
now, because if you delete a ressource from the tree, you'll
have unused space in the middle of the file. You may use this
space for other, new ressources of this file or you may compact
this file or you may drop the blocks associated with the file
at this offset and live with sparse files.

If you compact the file, you will soon learn that updating
ressources in a file becomes a quite inefficient process - you
wouldn't want to store user defaults in a large application and
then compact the applications ressource fork each time the user
terminates the application. And what if multiple users are
updating the ressources of an application simultaneously?

You may live with sparse files, but this requires that each
ressource in a file be aligned on a block boundary to be
efficient, creating lots of internal fragmentation in a file
with many ressources. Also, it is in no way different from a
regular "directory-with-files interpreted as an application"
approach.

And what about access control? You would want ownership and
access permissions for each and every ressource in a ressource
fork, to hinder users from changeing each others defaults.

Well, to me all this looks like you end up with the Nextstep
approach if you do it properly. And look mum, no kernel change
at all!

Kristian
--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897

 
 
 

Resource forks

Post by Paul Flinder » Mon, 19 May 1997 04:00:00




> > For executables, an ELF section would do the job.
> > (executables you can run but not read are the exception)
> > Can we standardize on a format? I'd guess a predefined
> > palette of "Netscape + VGA + transparent" is good.
> > Require these: 16x16 32x32 64x64 128x128.

> Please tell me a reliable way an application can find the file it is
> started from.

> This request seems innocent, but it will waste alot of bandwidth!

OK, OK I know but I can't resist :-)

This is indeed an old chestnut.  In general you can't. If bash is the
shell then just look up the "_" environment variable.  Otherwise in
*practice* looking up argv[0] using the PATH environment or relative to
the current directory as appropriate works well enough most of the time.
It is trivial to arrange that a program can't find it's own ececutable
using either of these methods.

However since this is comp.os.*linux*.development.system I can
guarentee** to be able to open my executable as a file or be able to
determine the device+inode pair that I'm running by either open(2)ing
/proc/self/exe or doing a readlink(2) on /proc/self/exe. Given device
plus inode I can find at least one pathname for the executable but I
can't be certain that it's what the user used.

** Assuming that I have /proc mounted of course.

There's no real point in arguing about this.  Unix has a many to one
mapping from pathnames to files. Given just the file (as inode or file
descriptor) there's no way to find out which of the names was used.

I haven't checked but I suspect that you can't find out which shortcut
was used to start an application in Windows95/NT 4 either.

TTFN

Paul.

 
 
 

Resource forks

Post by david parso » Mon, 19 May 1997 04:00:00




>Right.  That's why resource forks would be very useful.  Currently
>you have to manually configure all those .cshrc, .login, .Xdefaults,
>etc.  Lots of Unix newbies are not up to that.  I am trying to
>come up with a solution for newbies, not for you and me.

  You're not asking for resource forks, then.  I'd imagine that if I was
  going to build a resource fork for, say, /bin/bash, I'd take whatever
  the global bash rc file is, drop it into the resource fork and let
  bash parse it in the usual way.  (Why?  Because it's useful to have
  all the configuration files and scripts for this language be the same,
  so once you've learned the language for one script, you've learned
  them all.)   A shell configuration editor that could write rc files
  would be nice, but that has absolutely nothing to do with a resource
  fork.

                ____

                 \/

 
 
 

Resource forks

Post by david parso » Mon, 19 May 1997 04:00:00




>Otherwise known as extended attributes. Sure, easily done (doesn't ext2
>have support for extended attributes on files?), and yes, they would be
>very useful. Unfortunately... Unix doesn't use EA's. If you implemented
>EA's, then it's not Unix.

   That's rubbish.

   Once upon a time, Unix didn't have ACLs either.  And unless you're a
   pedant about Linux != Unix, there is a HPFS filesystem for Linux,
   which means that given the appropriate flavor of Unix, Unix DOES use
   EA's.

Quote:>Since the biggest strength of Unix is the
>compatability (the same program is trivially ported between platforms),

   *cough*

   I'm a systems administrator.  I just came off a session doing organ
   transplants between two Alphastations, because the 6 hours spent
   doing that was a lot easier than pulling the old box, putting in the
   new box, and spending 15 hours rebuilding a bunch of `trivially
   ported' applications.   If trivially porting applications is the
   biggest strength of Unix, I might as well go out and buy some more NT
   programming manuals. (As a side-note, does anyone else hate the
   cheapy styrene boxes that Alphastations come in?  Every time I pull
   one of the boxes apart, another shower of little plastic bits comes
   off the case.  At least duct tape works to hold the things together,
   but I can imagine that dec will be moderately unhappy when the box is
   returned, nicely held together with gray tape.)

Quote:>A more portable way is to use hidden files. Check out how xv stores image
>thumbnails as an example.

   A more portable way to do this is to write a wrapper library that
   uses whatever the underlying file system, or database, or whatever
   access method you might want to use, provides.  An opaque preferences
   folder is a happy preferences folder.

                 ____

                  \/