Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ncar!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Manx help
Message-ID: <8810311911.AA06094@cory.Berkeley.EDU>
Date: 31 Oct 88 19:11:49 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 39

>First, what evidence do you have that ParentDir returns a lock that can't
>be freed? There really isn't a close relationship between ParentDir and
>CurrentDir.

	ParentDir() returns a NEW LOCK, right?  Therefore, you *MUST*
UnLock the lock returned by ParentDir() eventually before exiting.  ParentDir()
does NOT touch the lock you give it, it just uses it to find the parent and
create a new lock for the parent and return that.

>Secondly, I believe that if you don't CurrentDir back to the original dir,
>you should free the original lock... otherwise it'll just hang around taking
>up space and keeping you from deleting the directory. You should only do this
>if you're writing a replacement to CD.

	No you can't!   If Program A has some notion of a current directory
and calls program B, which then CHANGES the current directory and returns
without restoring the old lock (or worse, actually UnLock()s it), Program A
comes back and *poof* the nice lock pointer it cached now causes a system
crash.

	Now, UnLock(CurrentDir(newlock)) is perfectly acceptable, but only
if you save/duplicate the original lock in the beginning of your program,
and restore it at the end:

	Forgive the lack of error checking in line 4 of this example:

main()
{
    struct Process *proc = FindTask(NULL);
    long originallock = CurrentDir(DupLock(proc->pr_CurrentDir));

    dostuff(): (  in which you can do lots of:  
	UnLock(CurrentDir(yet-another-lock-you-just-created))
    )

    UnLock(CurrentDir(originallock));
}

					-Matt