hatcher@INGRES.BERKELEY.EDU (Doug Merritt) (06/23/87)
The new shell 2.06M, although very nice in many ways, including correct expansion of wildcards even when filenames have embedded blanks (I'm not aware of any other shell that correctly supports this important case), it does have this one nasty bug. Say you have a diskette that has files with wierd dates. "list" shows the dates as Future, shell 2.04M "dir" shows them as negative (e.g. "-844-Jan-42 00:-31:-41"). Hey, I don't know how they got that way... but I've got two diskettes of commercial software, and three of public domain software, that have wierd file dates like this. Anyway, if you do "dir" or "echo *" in such a diskette, shell2.06M bombs badly. It gurus 810000005, and destroys the restartable ram disk while it's at it. Or maybe it just corrupts the free memory list, and AmigaDos destroys the ram disk before guru-ing. In any case, there really aren't that many kinds of crashes that screw up the RRD, so this is really a bummer. Interestingly enough, the first sign of the crash is that the disk grinding (from the directory listing) stops, then the screen flickers, and finally the guru pops up, and the times that I hit CTRL-A-A real fast as soon as I saw it going into that sequence, the RRD survives, whereas the RRD *always* dies if I let it go all the way to the guru message. First time I've felt I had any important measure of control *during* a crash! :-) Doug
hull@hao.UCAR.EDU (Howard Hull) (06/23/87)
In article <8706231137.AA11478@ingres.Berkeley.EDU>, hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: > > Say you have a diskette that has files with wierd dates. "list" shows > the dates as Future, shell 2.04M "dir" shows them as negative (e.g. > "-844-Jan-42 00:-31:-41"). Hey, I don't know how they got that way... > but I've got two diskettes of commercial software, and three of public > domain software, that have wierd file dates like this. Anyway, if > you do "dir" or "echo *" in such a diskette, shell2.06M bombs badly. > It gurus 810000005, and destroys the restartable ram disk while it's > at it. Or maybe it just corrupts the free memory list, and AmigaDos > destroys the ram disk before guru-ing. In any case, there really aren't > that many kinds of crashes that screw up the RRD, so this is really > a bummer. I did an interesting experiment with the Drew Shell, the 'cp' program recently put to the net, and two versions of the Amiga 'Copy' command. Having gotten the 2.06 shell installed, I decided to rebuild my workbench using the shell and a script file (something it does a great job with!). While copying some files to RAM:, I noticed that the dates ended up with very peculiar formats (like the ones you show above). Since the copy routine is different in 2.06 I thought it might have a bug in it. To co-test the problem, I tried the 'cp' program (recently much discussed on the net). It did the same thing - munged dates. So I tried the XCopy program (another date copying copy program recently submitted to the net - sans source). It worked ok. So I continued on... While preening the contents for the source disk, I noticed that my Ram-Handler was listed as 04-Nov-86 6244 bytes, whereas the 1.2 enhancer had it as 06-Nov-86 6308 bytes. Hmmmmn. So I tried the 6308 byte version and shell "copy" duplicated a file in ram with the original date and no garbage in the dir date. Conclusion: check to see that you are not using gamma versions of the 1.2 Ram-Handler (I got my boogie bad one with the update from Aegis for the update to Aegis DrawPlus). Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | decvax!noao | mcvax!seismo | ihnp4!seismo} !hao!hull for domain mailers: hull@hao.ucar.edu