🚀 go-pugleaf

In article <1990Oct11.212541.18365@hoss.unl.edu> 252u3130@fergvax.unl.edu (Phil Dietz) writes:
>I've written a Zoo2Lzh program that does a list and converts zoo->lzh
>through the system() command.  Well anyway, everything goes
>well until it hits the WHILE (ExNext(lock,&fi)); command.  When it
>hits it, it GURUS with a Disk Corrupt error.  For somereason, if I
>change it to (Examine(lock,&fi), the program works, BUT all the old
>files have to be READ ALL OVER AGAIN!

	Where is the lock coming from?  When was the original Examine() done?
(You of course know that you must Examine() a directory lock before
ExNext()ing...)  Every time you do Examine(), you reset and ExNext will
take you through all the files in the directory.  Note that changing a
directory while examining it will have, at best, "funny" effects.  Deleting
files causes the worst problems, since the file being examined with ExNext
might be deleted, leaving no way to find the next file in the directory, or
worse yet, it might have been reallocated for a new file header in a different
directory.  In the ram disk, it might end up referencing deallocated memory,
leading to a guru or other very bad result.

>Do I have to lock the directory again or call another function to a
>directory, if I've heavily changed the contents earlier?  Or do I have
>to put in a wait cycle or something to allow all the floppy acces to be
>done before it gets the next (ExNext(lock,&fi)) entry....

	No, but to re-examine a directory, you must start with Examine(),
and call ExNext() until you get ERROR_NO_MORE_ENTRIES.

	It really isn't clear what you're doing, I'm afraid.  remember that
people trying to help you have never seen your source code - please always
try to post something that has all relevant information included, and if
possible isolate any problems down as far as possible.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"

In article <15327@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:

>	Where is the lock coming from?  When was the original Examine() done?
>(You of course know that you must Examine() a directory lock before
>ExNext()ing...)  Every time you do Examine(), you reset and ExNext will
>take you through all the files in the directory.  Note that changing a
>directory while examining it will have, at best, "funny" effects.  Deleting
>files causes the worst problems, since the file being examined with ExNext
>might be deleted, leaving no way to find the next file in the directory, or
>worse yet, it might have been reallocated for a new file header in a different
>directory.  In the ram disk, it might end up referencing deallocated memory,
>leading to a guru or other very bad result.

What is the "accepted" way of scanning through a directory using Examine(),
ExNext() while deleting the files as you go?  Is there an alternative to
having to restart the scan each time you delete a file?

--
Mike Oliphant		    UUCP: alberta!herald!telepro!oliphant
			Internet: oliphant@telepro.uucp
			 FidoNet: (1:140/91) - ZMH only
*
* Call TelePro, the development system for DIALOG Professional
*
*   Phone: +1 306 249 2352	2400/9600/14400 bps HST
*	   +1 306 652 2084	300/1200/2400 bps
* FidoNet: (1:140/90)
*

In article <oliphant.4664@telepro.UUCP> oliphant@telepro.UUCP (Mike Oliphant) writes:
>What is the "accepted" way of scanning through a directory using Examine(),
>ExNext() while deleting the files as you go?  Is there an alternative to
>having to restart the scan each time you delete a file?

Just as a guess, I would say the easiest way would probably be to allocate
memory and hold the names of the files you want to delete all at once. 
If you run out of memory, delete those files and restart the scan. - Darren
-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee -----

In article <ggk.657252410@tirith.UUCP> ggk@tirith.UUCP (Gregory Kritsch) writes:
>I've found that double buffering works rather well:
>oldfib = NULL;
>while (ExNext(lk, fib)) {
>	if (oldfib) remove(oldfib->fib_Filename);
>	else oldfib = malloc(sizeof(struct FileInfoBlock);
>	CopyMemQuick(fib,oldfib,sizeof(struct FileInfoBlock);
>}
>remove(oldfib->fib_FileName);

But maybe this won't work in future versions of the FFS that 
scan from both ends inwards.  Its dependance on current activity
like this that makes compatibility difficult. 

A minor point here: this particular code also won't work if the
directory is empty...

		   -- Darren
-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee -----

new@ee.udel.edu (Darren New) writes:
>In article <oliphant.4664@telepro.UUCP> oliphant@telepro.UUCP (Mike Oliphant) writes:
>>What is the "accepted" way of scanning through a directory using Examine(),
>>ExNext() while deleting the files as you go?  Is there an alternative to
>>having to restart the scan each time you delete a file?

>Just as a guess, I would say the easiest way would probably be to allocate
>memory and hold the names of the files you want to delete all at once. 
>If you run out of memory, delete those files and restart the scan. - Darren

I've found that double buffering works rather well:

oldfib = NULL;
while (ExNext(lk, fib)) {
	if (oldfib) remove(oldfib->fib_Filename);
	else oldfib = malloc(sizeof(struct FileInfoBlock);
	CopyMemQuick(fib,oldfib,sizeof(struct FileInfoBlock);
}
remove(oldfib->fib_FileName);

You have to do the copy, since you must use the same FileInfoBlock with
ExNext (and despite Transactor's claim that only the fib_Key field must
be preserved, the AmigaDOS manual states the entire structure must be
preserved).

>--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
--
  Gregory Kritsch                          | University of Waterloo
    Fido:  1:221/208.11110  [1:163/109.30] | 1A Computer Engineering
    UUCP:  ggk@tirith.UUCP                 |--------------------------
           ...!watmath!xenitec!tirith!ggk  | Amiga Fanatic