| Author |
Message |
   
Victor Johnson
Username: flacop
Registered: N/A
| | Posted on Friday, Aug 31, 2007 - 16:38: | |
In working on a complex carve operation, I have encountered a loop problem. Is it possible to have a FIND command start or resume from a specific offset? In my case, I begin a find for a file header and when found, mark a block and execute another find within that block. When I return to the original find it begins at byte 0, effectively creating a fixed length loop. Below is a simple block of what I am doing: BEGIN find header down if found mark position jump to NARROW endif close & terminate NARROW mark an xFF block at position find astring in block if found identify big block carve it endif set position after block jump to BEGIN None of my manipulations seems to cause the BEGIN find command to start anywhere but byte 0. |
   
Stefan Fleischmann
Username: admin
Registered: 1-2001
| | Posted on Friday, Aug 31, 2007 - 17:07: | |
> Is it possible to have a FIND command start or resume > from a specific offset? Yes, with the down parameter, if that specific offset is the cursor position. |
   
Victor Johnson
Username: flacop
Registered: N/A
| | Posted on Friday, Aug 31, 2007 - 18:16: | |
Yet in my example, the script never advances past the first 'hit'. The header is found, the subroutine executes and marks an xFF sized block, fails the iffound and returns to the original find...which then finds the same 'hit' in a continuous loop. Should I set the position marker BEFORE the find command in the (BEGIN) section rather than at the end of the (NARROW) routine? i.e. x=0 BEGIN position=x find down ..... NARROW ..... x = offset jump BEGIN Thanks for the help Stefan. |
   
Stefan Fleischmann
Username: admin
Registered: 1-2001
| | Posted on Friday, Aug 31, 2007 - 18:27: | |
If by "set the position marker" you are referring to the Goto or Move command, doesn't matter. |
   
Victor Johnson
Username: flacop
Registered: N/A
| | Posted on Saturday, Sep 1, 2007 - 0:36: | |
Perfect! Got it to work properly using the second method. Nicer coding that way, too. Thanks again, Stefan |