markv@kuhub.cc.ukans.edu (05/13/91)
In article <91133.150111GUTEST8@cc1.kuleuven.ac.be>, GUTEST8@cc1.kuleuven.ac.be (Ives Aerts) writes: > I have to implement an examine next function for my device > and can't find one that works efficiently. That is a problem. > From what I've read I conclude that I can only use the disk key > and filename information from the supplied FileInfoBlock to > determine what's the next directory entry to examine. Technically correct. > The supplied lock doesn't have to be the same as the one passed > in the previous examine or examine next call and the file info > block can be a new one with the diskkey and filename fields > copied from the previous FileInfoBlock. Technically true, but note that the 1.3 FFS will crash hard if you much with ExamineNext() to hard, but thats Commodores fault, as they say in the 2.0 Autodocs, you have to account (and it helps), for almost any combination of situations. > I allso can't store > any intermediate information in a structure or variable owned > by myself 'cos there's no way to find out when I can clear > this information (which would lead to an out of memory > situation after a number of examine/examine next calls) > Therefor only the diskkey and filename from the last > FileInfoBlock can be used. Correct me if this is wrong. Not quite true. Every ExamineNext() call can vary a lot, but one absolute requirement is that it be based off a Lock() from your handler. Of course one Lock() can but recycled several times, etc. but it gives you a place to start. I think this fact is used by Handlers like RAM that dont really have fixed keys. > The solution I came up with is this one: > Allways examine the directory entry with the smallest > diskkey larger than the one in the FileInfoBlock. > This way I won't run into problems if the last diskkey > points to a file or directory that has been deleted since > the examine next call. > Trouble is that I have to traverse the whole directory > each time to find the smallest diskkey I can pass on. > This is quite an amount of overhead for large directories. > I allso won't catch any new files with a small diskkey > that appear while scanning the directory. The trick is to handle the situation gracefully, but not nessescarily perfectly correctly. Some program that is extensively mucking with (deleting, moving, renaming, etc) with things in the middle of ExNext()ing a dir shouldn't expect any particular behavior. The AmigaMail article on the 2.0 dos packets has some notes on behavior. Also, with 2.0, most programs (hopefully) will just use the ExAll() when they really need an accurate snapshot of a dir. > Anyone who came up with a better solution ? And to the > folx at commodore (I guess randell should know this) how > does amigados do this ? With 1.3, terribly. It (from my expiriments) requires that the Lock() for ExNext be a dir (the docs dont say this, but it crashes if it isn't), and generally just returns the end of a dir if things get out of hand. I haven't tried much with 2.0, but then there is ExAll. > ------------------------------------------------------------------------ > Ives Aerts | IBM definition SY-34378 > GUTEST8@BLEKUL11.BITNET | A signature consists of sequences of > gutest8@cc1.kuleuven.ac.be | non-blank characters separated by blanks. > ------------------------------------------------------------------------ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GUTEST8@cc1.kuleuven.ac.be (Ives Aerts) (05/13/91)
I have to implement an examine next function for my device
and can't find one that works efficiently.
From what I've read I conclude that I can only use the disk key
and filename information from the supplied FileInfoBlock to
determine what's the next directory entry to examine.
The supplied lock doesn't have to be the same as the one passed
in the previous examine or examine next call and the file info
block can be a new one with the diskkey and filename fields
copied from the previous FileInfoBlock. I allso can't store
any intermediate information in a structure or variable owned
by myself 'cos there's no way to find out when I can clear
this information (which would lead to an out of memory
situation after a number of examine/examine next calls)
Therefor only the diskkey and filename from the last
FileInfoBlock can be used. Correct me if this is wrong.
The solution I came up with is this one:
Allways examine the directory entry with the smallest
diskkey larger than the one in the FileInfoBlock.
This way I won't run into problems if the last diskkey
points to a file or directory that has been deleted since
the examine next call.
Trouble is that I have to traverse the whole directory
each time to find the smallest diskkey I can pass on.
This is quite an amount of overhead for large directories.
I allso won't catch any new files with a small diskkey
that appear while scanning the directory.
Anyone who came up with a better solution ? And to the
folx at commodore (I guess randell should know this) how
does amigados do this ?
------------------------------------------------------------------------
Ives Aerts | IBM definition SY-34378
GUTEST8@BLEKUL11.BITNET | A signature consists of sequences of
gutest8@cc1.kuleuven.ac.be | non-blank characters separated by blanks.
------------------------------------------------------------------------