🚀 go-pugleaf

> ONLY unlock locks that you get from Lock() or DupLock().  It seems that
> when using CurrentDir(), the system simply hands you a pointer to a lock
--
Here you have forgotten that you must UnLock() locks from CreateDir()
also.

> So the RULE is:
> 
> 	NEVER UnLock any lock given to you by either
> 	CurrentDir() or ParentDir().  ONLY UnLock a
> 	lock provided to you by Lock() or DupLock().
> 	Those BELONG to you.  The others just might
> 	have been created by the system and it will
> 	not realize you have killed them -- when it
> 	tries to reuse them, the GURU may visit.

Are you sure about this?  My experience has been otherwise.  When coding the
Amiga routines for Zoo,  I looked at a C-A example of using the new SET_DATE
packet in 1.2.  It did not free the lock from ParentDir() and in the AmigaDOS
manual's write up on UnLock,  it says that UnLock() is to free locks
obtained from Lock, DupLock, or CreateDir.  However I kept getting reports
that the Amiga version of Zoo would leave locks on directories when the 'x//'
option was used.  At first I thought that somehow the lock from CreateDir
was not being freed,  but then John Hiday pointed out to me that the same
problem occured when 'x/' was used... this was the clue I need to find the
problem... it was the lock from ParentDir that was being left... adding the
call to unlock it fixed the problem and has not seemed to cause any new ones.

So I think the UnLock function docs should have ParentDir added to the list
of locks to free.  If am wrong about this please let me know so I can correct
the code in the Amiga version of Zoo.
-- 
Brian Waters              <backbone>!{iuvax|pur-ee}!bsu-cs!jbwaters
                                          uunet!---/