Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!stpeter!cmcmanis From: cmcmanis@stpeter.Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga.tech Subject: Re: CurrentDir Message-ID: <133343@sun.Eng.Sun.COM> Date: 22 Mar 90 23:23:30 GMT References: <00173.AA00173@starsoft.UUCP> <133060@sun.Eng.Sun.COM> <1332@quintus.UUCP> <1990Mar21.082549.9252@santra.uucp> Sender: news@sun.Eng.Sun.COM Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 22 An amendment to the rule of "Don't unlock locks you don't own" is required. 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. So the Amended rule is : Don't Unlock locks you don't own. If you swap locks with CurrentDir then the lock you gave away is no longer yours but the lock you got is so you can unlock it. However, if you are started from workbench, preserve the original current directory lock and return it before returning to workbench. (At least until they fix the bug in Workbench) --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "If it didn't have bones in it, it wouldn't be crunchy now would it?!"