dean@coplex.UUCP (Dean Brooks) (10/13/90)
I wanted to catch your eye with the subject line of this message
because I thought this was important enough to post about.
It seems there may be an inherent flaw with the recently posted program
Dir-Work 1.12 that appeared recently in comp.binaries.amiga. It took
only 10 seconds of using the program before it totally trashed my
hard drive.
I had selected a directory from the selection list presented by
Dir-Work and chose the "move" gadget to move it. At that point, I didn't
want to proceed so I exited the program gracefully (by clicking the
close requester).
Unfortunately, Dir-Work had already moved the directory link into
oblivion and I didnt realize it until it was much too late. I tried to
patch things up with a block editor to no avail.
I dont know if this is a bug or an inherent design flaw, but if it
is part of the programs design to have a state where a directory is in
limbo while waiting for a user response, it a bad choice on the authors
part. If any file linking/unlinking is to be done, it should be done
in one fell swoop, and NOT in bits and pieces. Most certainly things
should be done to restore conditions to a sane state if program
termination is requested.
I wouldnt have posted anything, but I felt that 10 seconds to completely
wipe out an 80meg hard drive deserves attention... Thanks...
( I know, I should have been more careful with a program I had never
used before, but hey, I assumed it had been tested thoroughly. Of
course we know what happens when you assume (-; )
--
dean@coplex.UUCP Dean A. Brooks
Copper Electronics, Inc.
Louisville, Ky
UUCP: !uunet!coplex!deanins778u@vax4.cc.monash.edu.au (mr c.r. hames) (10/18/90)
In article <199@coplex.UUCP> dean@coplex.UUCP (Dean Brooks) writes: > I had selected a directory from the selection list presented by >Dir-Work and chose the "move" gadget to move it. At that point, I didn't >want to proceed so I exited the program gracefully (by clicking the >close requester). > > Unfortunately, Dir-Work had already moved the directory link into >oblivion and I didnt realize it until it was much too late. I tried to >patch things up with a block editor to no avail. > > I dont know if this is a bug or an inherent design flaw, but if it >is part of the programs design to have a state where a directory is in >limbo while waiting for a user response, it a bad choice on the authors >part. If any file linking/unlinking is to be done, it should be done >in one fell swoop, and NOT in bits and pieces. Most certainly things >should be done to restore conditions to a sane state if program >termination is requested. > You do NOT know what you are talking about. You cannot exit until the move operation is completed. It is done in one go. No option to stop the operation comes up. If you select the close box, it will not know or do anything until it has finished the move. Never has such a problem reported. And yes I am using it on a harddisk. You did not try to mail me to find out what really caused the problem but instead flame. Why you decided not to proceed probably has more to do with your problem...... >-- >dean@coplex.UUCP Dean A. Brooks > Copper Electronics, Inc. > Louisville, Ky >UUCP: !uunet!coplex!dean Sorry to add to the heavy trafic on comp.sys.amiga but since this person posted I felt I must answer so people can see the other side. -- Chris Hames - C/Assembler programmer | Fish: DirWork,FSDirs,VMK..| /~\/ \ 3:633/301.0 (Fido) | Commercial: Classified. | ( OZ ) mail ins778u@vax4.cc.monash.edu.au +---------------------------+ `--'\_/ OR uunet.uu.net\!vax4.cc.monash.edu.au\!ins778u o