Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Locking the "chooser" user name?
Message-ID: <7720@hoptoad.uucp>
Date: 20 Jun 89 22:06:16 GMT
References: <1889@dogie.macc.wisc.edu> <22951@santra.UUCP> <7697@hoptoad.uucp> <22959@santra.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 83

In <22951@santra.UUCP> jmunkki@kampi.hut.fi.hut.fi (Juri Munkki) writes:
>How about setting the protected bit (with ResEdit) after setting the names?
>I don't know how the chooser would react to this, but it might work.

In article <7697@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>I tried it and got confusing results.  First, I was able to change the
>name even with the 'STR ' resource's protected bit set.

In article <22959@santra.UUCP> jmunkki@kampi.hut.fi.hut.fi (Juri Munkki) writes:
>This is because the current handle in RAM is changed. This means that
>anyone who really wants to change the username can change it. I think
>this is a good feature, but someone might disagree.

First, thanks for the explanation.  I hadn't realized that when dealing
with a System file, the RAM copy would open first if there was one.
Then of course closing the window does a ReleaseResource and the next
fetch is from the disk.  This approach could blow away some system
software if it assumes that a non-purgeable resource that's been read
in once will always be in RAM, but otherwise, it makes sense.

Second, since you agree that this doesn't prevent the user from
changing the Chooser name, what are we arguing about?  And if the goal
is preventing this change, how can you say this is a good feature?

>>It would appear that when the Chooser attempts to modify the 'STR '
>>resource, it receives an error.
>
>IM-I doesn't say if this should create an error. In fact, there is no
>error for this situation. I took a look at the chooser code and it
>doesn't check for any errors. It probably should, because the system
>file might be locked in some other ways too. It just calls HNoPurge,
>ChangedResource, WriteResource and HPurge.

(So in fact the Chooser name change lasts only until the System Heap
becomes too full for a Memory Manager request and the 'STR ' is purged.)

Thanks; like I said, I didn't feel like poking around in the DA code.
I can't believe that the Resource Manager doesn't stick an error code
in ResError when you try to write a protected resource, though!
(Actually, having disassembled large parts of the Resource Manager, I
can believe just about anything....)

>AddResource is never called when writing the resource. I think it
>is called when chooser is opening. The first time you open the
>chooser when the STR does not exist, it takes a lot longer than
>normally.

That appears to be correct; the 'STR ' for the name is not present in
the copy of the desk accessory in the "Desk Accessories" file on the
Apple system disks.

>I knew there would be a copy in RAM and the good thing is that the
>user thinks the name is changed when it's not actually written to
>disk.

The good thing?  In what way is a misleading feature that only partially
does the job a good thing?

The misleading part is especially bad.  Just we we need is for the users
of a Macintosh to be less certain that it will behave predictably and
obviously, so they will rveert to the "I'm afraid to type 'help' because
it might erase all my files" so common on other machines.  If there is a
good solution, it is one that doesn't confuse the user.

>I was sure that it would work and I read my Inside Macintosh before posting... 

You knew that it *wouldn't* work and you went ahead and posted it without
any warnings to that effect....

PS.  Does anyone know how reserved DA ids are enforced by the Font/DA
Mover?  I assume that how it works is that any DA which is in the
reserved range in the suitcase file will be copied with that ID, but
suppose there is already a different DA there -- what happens?  Just
curious because the Chooser now sits on the space that the Puzzle used
to take up, and I was wondering what would happen if you had an old
Puzzle and installed the Chooser.  I don't have an old Puzzle or I'd
just check.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com
Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934

"Americans will buy anything, as long as it doesn't cross the thin line
 between cute and demonic." -- Ian Shoales