🚀 go-pugleaf

In article <679@ardent.UUCP> rap@ardent.UUCP (Rob Peck) writes:
>main()  
>{
>	/* CORRECT METHOD */
>
>	struct FileLock *testlock, *aarrgghh;
>	testlock = Lock("RAM:",ACCESS_READ);
>	aarrgghh = CurrentDir(testlock);
>
>	/* aarrgghh is a pointer to the lock on the
>	 * directory that the CLI started from...
>	 * it may still need that lock sometime later.
>	 * If we free it by UnLock, we mess things up.
>	 */
>
>	UnLock(testlock);
>	/* Did nothing more than move current CLI's
>	 * current directory to ram:
>	 */
>}

	Are you *sure* about this, Rob?

	It strikes me that, if you UnLock() the lock you handed to
CurrentDir() (and therefore the system), you'll pull the rug out from under
the CLI's feet when it tries to access that lock.

	I thought, as another Net person said (name forgotten; sorry), that
CurrentDir() trades locks with you.  You hand CurrentDir() a lock on the
directory you want to go to.  CurrentDir() takes it away from you, and
gives you posession of a lock on the directory you used to be in.  This is
how I do it in Onion, and I haven't had any problems yet.

	What is the final story?  Naturally, the DOS docs obfuscate this
point.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	INET: well!ewhac@ucbvax.Berkeley.EDU
 \_ -_		Recumbent Bikes:	UUCP: pacbell > !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor