drew@cgfsv1.dec.com (Steve Drew) (12/17/86)
I've found what appears to be a very bizarre bug under 1.2, that
cause's disk's to get trashed. After writing the commandline editing code
for shell and using it and 1.2 for a couple of months I kept getting the
odd disk go bad. Seem'd to usually be when doing a makedir or a copy
or creating a new file. We'll I happend to pick up a 5 1/4" transformer
drive this weekend and the problem was even worse on it, in fact I
could easily reproduce it: All I had to do was fire up two shells in one
of them I did a 'forever copy df2:tmp/* ram:' and the other shell all
I had to do was hit a few RETURNS and then df2: would stop with a read
error. The only way to get df2: to read again was to power it off.
Now I have tried this on other Amiga's and another 5 1/4" drive. I was'nt
able to reproduce it on a 3 1/2" drive it seemed more intermittent on them.
After playing arround with my code for a while I determined that the problem
occured when setting the console back to a raw. (I set it to a raw, get
the line and then set it back to con while command is executing).
So then I thought maybe I'm missing something with the packet handling
to/from the console port, but no go.
To make a long story short, turns out that I had a WaitForChar(Input(),1L)
check to see if there is already a full terminated line of input
just before doing a setraw() on the console. If I removed the WaitFor..
call then no disk problems. More interesting I found that I could use
the WaitForChar() as long as I used anything other than 1L for the wait time.
Just to make sure that it was'nt anything else in my code doing this I
took Phillip Lindsay's example Sendpacket.c where he changes the console
to/from raw mode, and change the while statement to something like this:
And yes this still caused read errors'. So I guess then it must be a weird
bug under 1.2. (I'm using 1.2 33.46)
arg[0] = DOSTRUE; /* change to raw */
res1 = sendpkt(conid,ACTION_SCREEN_MODE,arg,NARGS);
while((c1 = getchar()) != 27) {
putchar(c1);
if (c1 == 13)
arg[0] = FALSE; /* change to con */
res1 = sendpkt(conid,ACTION_SCREEN_MODE,arg,NARGS);
WaitForChar(Input(),1L); <====== This causes the problem.
arg[0] = DOSTRUE; /* change to raw */
res1 = sendpkt(conid,ACTION_SCREEN_MODE,arg,NARGS);
}
}
I have had at least 2 other people who have seen this disk problem
using shell. So now that I've found the workaround I will post a
new uuencode Shell 204m. Because of the number of request's I will also
post the sources to Shell 204M here.
==========================================================================
Steve Drew at ENET: CGFSV1::DREW
ARPA: drew%cfgsv1.dec.com@decwrl.dec.com
USENET: {decvax!decwrl}!cgfsv1.dec.com!drew
==========================================================================rmariani@watmum.UUCP (Rico Mariani) (12/18/86)
In article <6977@decwrl.DEC.COM> drew@cgfsv1.dec.com (Steve Drew) writes: > >I've found what appears to be a very bizarre bug under 1.2, that >cause's disk's to get trashed. After writing the commandline editing code >for shell and using it and 1.2 for a couple of months I kept getting the >odd disk go bad. Seem'd to usually be when doing a makedir or a copy >or creating a new file. We'll I happend to pick up a 5 1/4" transformer >drive this weekend and the problem was even worse on it, in fact I >could easily reproduce it.... I'm glad I'm not the only one who had this problem. I thought I was losing my marbles or something. So far I've been "lucky", all the hits have been on my root block which (thanks to DiskSalv or DiskDoctor) are 100% harmless (pheww!). There is one other problem that I've noticed though, I don't know if I can blame the shell or not. Try this sequence of commands in some scratch direcotory on any disk (or ram:) % dir % rm *.o % dir The second dir produces NO OUTPUT! Yipe! But all is not lost, if you cd back to where you think you should be % cd $_cwd % dir things are really OK after all, nothing drastic has happened. While I'm talking about this new shell, Steve can you give me a faster way to move along a command line that I'm editing somehow (like say shift cursor keys to move to the start and end of line or something). It's really painful when you type ce df1:this/that/the/other/thing/too/why/not/even/this/ok and then you realize "gadzooks, I blew it waaaaay back in column 2". But all in all, I really love this new shell (except for the disk trashing) Good work! Could you post the code that passes the ^C signal along? I'm not sure how to do this... -Rico
drew@cgfsv1.dec.com (Steve Drew) (12/19/86)
>While I'm talking about this new shell, Steve can you give me a faster >way to move along a command line that I'm editing somehow (like >say shift cursor keys to move to the start and end of line or something). >It's really painful when you type > >ce df1:this/that/the/other/thing/too/why/not/even/this/ok > >and then you realize "gadzooks, I blew it waaaaay back in column 2". but that feature was already there. As per doc: KEY DEFINITIONS: Up Arrow Recal previous commands Down Arrow Recal commands Left Arrow Move cursor about command line. Right Arrow " " " " " DEL Delete char a head of cursor. ^A Toggle insert/overtype mode. ^D EOF (will exit shell). * ^E Put cursor at end of text. ^R Retype current line. ^U Erase entire line. ^X Erase entire line. * ^Z Put cursor at start of text. I would of used ^A for begining of line except that's kind of the standard for insert/overtype that I'm use to under vms. It would not be difficult to make shift arrows to do the same functions as ^Z and ^E. I just found them easier to type. (I also increase my key repeat speed under preferences.) /Steve.
john13@garfield.UUCP (12/25/86)
In article <743@watmum.UUCP> rmariani@watmum.UUCP (Rico Mariani) writes: >I'm glad I'm not the only one who had this problem. I thought I was >losing my marbles or something. So far I've been "lucky", all the hits >have been on my root block which (thanks to DiskSalv or DiskDoctor) >are 100% harmless (pheww!). Track 40, surface 0, perchance? The distinction between programs is an important one, since DiskDoctor will reformat the root block if it decides it's munged. DiskSalv I remember as making a *lot* of grinding noises, but maybe it is better at recovering files...DiskDoctor always loses >= 1/2 of them, since the root block (and 1 other, usually 36 or 43) is what always goes on my disks (drive mechanism, no doubt). Or maybe the changes in file placement under 1.2 lead to more failures with marginal drives? Either way, it would be nice to one day see a read/write error message that was non-fatal... Can't wait to see that clown! John