Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!eris!korn
From: korn@eris (Peter "Arrgh" Korn)
Newsgroups: comp.sys.mac
Subject: Re: Multi-launch under Appleshare  [was Re: What's the best NETWORK?]
Message-ID: <3284@pasteur.Berkeley.Edu>
Date: 11 May 88 21:54:00 GMT
References: <1814@uhccux.UUCP> <1815@uhccux.UUCP> <2229@polyslo.UUCP> <1072@aucs.UUCP> <3191@pasteur.Berkeley.Edu> <1076@aucs.UUCP>
Sender: news@pasteur.Berkeley.Edu
Reply-To: korn@eris.UUCP (Peter "Arrgh" Korn)
Organization: What, me organized???
Lines: 79

In <1076@aucs.UUCP>, paul@aucs.UUCP (Paul Steele) said:  
>In article <3191@pasteur.Berkeley.Edu> korn@eris.UUCP (That's me) writes:
>
>>I haven't used MacJANET, but I would be curious as to what happens when
>>...

The day after posting this, I got a chance to play with MacJANET a little.
Cleared things up a bit...

>...[comments about MacJANET and software list of apps. that are known
>    to work]...
>Hypercard doesn't work under MacJANET if loaded from a read-only volume,
>which is well know for Hypercard.

MacJANET works in generally the same fashion that the old Paradise hard
drives used:  You use a MacJANET utility to partion the hard drive on
your server into a MacJANET section, and a 'normal' section.  Within
the MacJANET section you then allocate fixed size partitions.  Users
can mount these fixed size partitions (no idea what the limit on # of
vols. is), and get at what's on them.  In your typical student environment,
most partitions will be locked, or read-only.

As far as I could tell, MacJANET doesn't do any magic when it comes to
apps. that want to modify themselves, or want to write to the directory
they are in.  They simply cannot.  So if, for instance, Macfoo, a word
procesing program of yester-year, decided it *needed* to create a
temporary file in the same directory that it is running from or die, it
will die.

Very few programs do this anymore.  Most, in fact, will create temporary
scratch files wherever they can.  If they can't do so in the directory
they are launched from, they'll try the boot volume, or the blessed system
folder (typically local, should always be writable).

HyperCard, in fact, works quite well with MacJANET (and not just version 1.2,
which has some neat nifty new features for dealing with read-only media).
The trick is to put the Home stack on a writable volume, preferable your
local floppy (if we are assuming a typical student environment).  The
HyperCard application itself can reside on a locked volume -- it doesn't
modify itself.  However, unless you are using version 1.2, all of the
stacks that you access must be writable.

An excellent way to test if a program that you want to run will work
on a MacJANET locked volume is to go up to a 2 floppy system, put an
unlocked boot disk into one drive, and a locked non-boot disk with
the application you wish to test into the other drive.  If you can
run the application without problems in this configuration, you should
have no problems running it from a locked server volume.

>We like MacJANET because it provides a pretty secure environment for our
>software. In the next version due shortly it will also limit the number
>of copies of a program in use, allowing us to buy fewer copies and restrict
>the usage.

More magic I'll have to see before I believe...


By the way, all of the above statements reguarding run-ability of applications
applies equally well to AppleShare volumes.  If you were to set up a system
with an AppleShare server, you could easily make a folder 'read-only' 
(which, in AppleShare terminology is called 'no make changes privilege') to
students, and all software that runs from locked local disks should work
without problems from that AppleShare folder.  If that software has the
'shared' (often known as the 'cached') bit set, it should multi-launch
without problems from a 'read-only' folder.  However, software which attempts
to *first* write temporary files to the same folder that they're launched
from will *not* multi-launch well from folders that are 'write-enabled'
unless their temporary file names are unique.  That is to say, if Macfoo
is launched from two different workstations from a folder that is 
'write-enabled', and it creates a temporary filename 'temp.file' from both
workstations in that folder, we're going to get the workstation's work
clobbered.    Hope I haven't hopelessly confused people with a less than
perfect explanation....


Peter
--
Peter "Arrgh" Korn
korn@ucbvax.Berkeley.EDU
{decvax,dual,hplabs,sdcsvax,ulysses}!ucbvax!korn