Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!rpi!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga.tech
Subject: Re: CurrentDir
Message-ID: <9965@batcomputer.tn.cornell.edu>
Date: 23 Mar 90 17:47:01 GMT
References: <00173.AA00173@starsoft.UUCP> <133060@sun.Eng.Sun.COM> <1332@quintus.UUCP> <1990Mar21.082549.9252@santra.uucp> <133343@sun.Eng.Sun.COM>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: LNS, Cornell University, Ithaca NY
Lines: 20

In article <133343@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes:
>The problem that most people run into with CurrentDir() and locks
>is that *Workbench* Caches the current directory lock and then 
>Unlocks it when your application exits. If you change directories
>by exchanging locks with CurrentDir and Unlock the one you got
>back, when Workbench goes to Unlock it you will be hosed.

Workbench doesn't exactly cache the current directory--it sends it to you
in the startup message.  The workbench startup message includes directory
locks on the directories containing the tool and any projects selected, 
and one of those (depending on how the you started the tool) will be the
same directory lock as the process current directory.  When your process
replies to the startup message (when it exits), workbench cleans up all
the locks in the startup message.  If you've already UnLock()ed any of
those locks, bad things happen.

In practice it works out to the same thing, and Chuck's rule still applies.

-Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley)
-Wilson Lab, Cornell University