252u3130@fergvax.unl.edu (Phil Dietz) (10/12/90)
I'm using Lattice 'C' 5.04 and I have a problem. 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! 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.... Help. Phil Dietz <<<=================--------- Cheap Ad ---------===================<<< Phil Dietz SWL Lincoln 550 MEGS! 2 lines 252u3130@fergvax.unl.edu (402)421-1963 IBM, GIFS, MAC, AMIGA
jesup@cbmvax.commodore.com (Randell Jesup) (10/23/90)
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!"
oliphant@telepro.UUCP (Mike Oliphant) (10/26/90)
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) *
new@ee.udel.edu (Darren New) (10/29/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 -----
smp@myamiga.UUCP (Steve Palm) (10/30/90)
In article <34801@nigel.ee.ude.edu>, new@ee.udel.edu writes:
DN> >What is the "accepted" way of scanning through a directory using
DN> Examine(),
DN> >ExNext() while deleting the files as you go? Is there an alternative to
DN> >having to restart the scan each time you delete a file?
DN>
DN> Just as a guess, I would say the easiest way would probably be to allocate
DN> memory and hold the names of the files you want to delete all at once.
DN> If you run out of memory, delete those files and restart the scan. -
DN> Darren
DN> --
DN> --- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
Wouldn't it be acceptable to 'follow' the scan, one entry behind? Then you
can delete the last-to-next entry. When you hit the end of the list, you
delete not only the last-to-next, but also right up to the end.
If there is a fault in the above logic, then so be it. ;^)
--
/// AMIGA: | Steve Palm, Sysop of FidoNet node 1:11/16
/// FOR THE | UUCP: {gatech,ames,rutgers}!ncar!asuvax!stjhmc!myamiga!smp
\\\/// CREATIVE | INTERNET: [not yet available]
\XX/ MIND |_________________________________________________________ new@ee.udel.edu (Darren New) (10/31/90)
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 -----
ggk@tirith.UUCP (Gregory Kritsch) (10/30/20)
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
ggk@tirith.UUCP (Gregory Kritsch) (10/31/20)
new@ee.udel.edu (Darren New) writes: >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. Is this a valid concern? I tend to think not. It seems obvious to me that ExNext() must go forwards only, not depending on backwards links, however, I can't quite lay down proof. I'll taking my chances with not absorbing memory and keep using it. It works on everything I've tried, even the super-sensitive RAM:. >A minor point here: this particular code also won't work if the >directory is empty... I did it again. I forgot to say "something like", indicating that this is an example meant30-18:39:12) rn,tirith,ggk rn shutdown (10/30-19:03:36) uucico,AmigaUUCP,- Startup V1.06D (10/30-19:04:07) uucico,xenitec,- DIALED xenitec (10/30-19:04:28) uucico,xenitec,- SUCCEEDED call to xenitec (10/30-19:04:34) uucico,xenitec,- OK Startup okay (user = ggk [Gregory Kritsch]) (10/30-17:38:20) rn,tirith,ggk rn shutdown (10/30-17:38:40) uucico,AmigaUUCP,- Startup V1.06D (10/30-17:39:49) uucico,xenitec,- FAILED call to xenitec (10/30-18:17:48) rn,tirith,- rn startup okay (user = ggk [Gregory Kritsch]) (10/