ins778u@vax4.cc.monash.edu.au (mr c.r. hames) (06/27/90)
I haven't seen a warning about the following situation so is this a bug
and if so is it fixed with 2.0.
Ok Kick 1.3 you Lock(),Examine(),CheckifDirectory,start getting directory:-
ExNext()
Delete the file you just got with ExNext using DeleteFile()
ExNext() - Now this gives you garbage from now on unless you Examine()
the directory your getting again.
Could someone at commodore tell me what other things will confuse ExNext()?
Also who is in charge of overseas developer support? I am not going to tell
you how bad the support is in Australia but would like to know who we can
mail who can improve the pathetic support that won't even answer a decent
question let alone register me. Maybe its because they have no idea &
realize I could provide better support given $100 and a phone line.
--
Chris Hames: ins778u@vax4.cc.monash.edu.au(internet)
C/Assembler!: Freely Avail: VMK,DirWork,FSDirs......(Fish etc)
Commercial: Classified.cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) (06/28/90)
You are correct, there is a bug in the Orig Filesystem (but I
believe it is fixed in FFS and the 2.0 FSes) That doing a
Delete(), between ExNext()s would cause problems. And it isn't
just your delete's some other task could delete a file out from
under you as well. This has to do with the hash chains getting
messed up when a delete occurs and the block that your current
lock points to gets an invalid next pointer in it.
I don't recall the fix off hand but Andy or Steve Beats may be
able to clue you in. In the short term, you can just "mark for delete"
those files you will be deleting (do a "duplock" and put them on
a list of to be deleted files) until you get to the end, and then
when you're done scanning the directory delete the files in the
to-be-deleted list.
--
--Chuck McManis Sun Microsystems
uucp: {anywhere}!sun!cmcmanis BIX: <none> Internet: cmcmanis@Eng.Sun.COM
These opinions are my own and no one elses, but you knew that didn't you.
"I tell you this parrot is bleeding deceased!"jesup@cbmvax.commodore.com (Randell Jesup) (07/05/90)
In article <3541@monu1.cc.monash.oz> ins778u@vax4.cc.monash.edu.au (mr c.r. hames) writes: > > I haven't seen a warning about the following situation so is this a bug >and if so is it fixed with 2.0. > >Ok Kick 1.3 you Lock(),Examine(),CheckifDirectory,start getting directory:- > ExNext() > Delete the file you just got with ExNext using DeleteFile() > ExNext() - Now this gives you garbage from now on unless you Examine() > the directory your getting again. > >Could someone at commodore tell me what other things will confuse ExNext()? It is a danger. Doing this to the ram-handler will cause a quick crash. With floppies/HD's, it doesn't happen as easily, but other problems can happen. For example, the file could be deleted, and another created using the same disk block. If this happened, you could end up "skipping" to another directory (very bad on a delete #?....) 2.0 is more resistant to this (I think it stops with an error in most cases). This is one of the prime reasons we created ExAll. -- 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!"
panon@cheddar.ucs.ubc.ca (Paul-Andre Panon) (07/20/90)
In article <13044@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > For example, the file could be deleted, and another created >using the same disk block. If this happened, you could end up "skipping" to >another directory (very bad on a delete #?....) 2.0 is more resistant to >this (I think it stops with an error in most cases). > > This is one of the prime reasons we created ExAll. So, is there filesystem support for ExAll() such that the fs will "sort and read file headers in a sequential (i.e. only-increasing or only- decreasing block #'s) manner" when appropriate (ie. OFS or FFS)? This would have the nice bonus of speeding up directory listings, no? I guess what I meant was `is ExAll() atomic at the fs level, as well and do the OFS and FFS take advantage of that?'? > >-- >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!" -- panon@staff.ucs.ubc.ca or USERPAP1@UBCMTSG or ppanon@undergrad.cs.ubc.ca or USERPAP1@mtsg.ubc.ca Looking for a .signature? "We've already got one. It is ver-ry ni-sce!"
jesup@cbmvax.commodore.com (Randell Jesup) (07/21/90)
In article <8786@ubc-cs.UUCP> panon@cheddar.ucs.ubc.ca (Paul-Andre Panon) writes: >In article <13044@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: >> This is one of the prime reasons we created ExAll. > >So, is there filesystem support for ExAll() such that the fs will "sort >and read file headers in a sequential (i.e. only-increasing or only- >decreasing block #'s) manner" when appropriate (ie. OFS or FFS)? This >would have the nice bonus of speeding up directory listings, no? > >I guess what I meant was `is ExAll() atomic at the fs level, as well and >do the OFS and FFS take advantage of that?'? In fact, we managed this for ExNext as well. This is why it slows down a lot if you UnLock() and re-Lock() on every ExNext (like the Manx scdir and lattice dnext) - it has to rebuild the table, which may mean scanning until it finds the same entry again. However, it's a BIG win under normal operation. -- 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!"