SYTANG@CSUGREEN.BITNET (SHOOU-YU TANG,PHYSICS DEPT,CSU,303-491-6372) (09/07/89)
After install the TOS 1.4 ROM into my 1040ST the ST display faster but it seem might has a bug in the Desktop show info. problem : When hightlighted either drive D or drive E of my 65MB hard drive and chioce SHOW INFO from the desktop to see how much space left. After the hard drive spin a while, an error box show up saying "This application cannot find the folder or file you just tried to access". Yet it works prefectly with drive C. And the old TOS has no problem with any drive. Is this cause by the TOS or the hard drive driver from ICD ? equiptment: 1040ST, ICD adaptor, Adaptec 4070 controller and Seagate 277R 65MB RLL hard drive, ICD Auto boot 2.1 , ICD hard drive driver 2.0 , Fold100 to increase the folders. And the hard drive is partitioned into 5 logic drives with 2 used by Magic Sac. Any hint on what might want wrong ? ============================== S.Y.Tang; Coloraddo State Univ.; Physics Dept. sytang@csugreen.ucc.colostate.edu sytang@csugreen.bitnet
hcj@lzaz.ATT.COM (HC Johnson) (09/11/89)
In article <89090707544479D.RRHH@CSUGREEN.UCC.COLOSTATE.EDU>, SYTANG@CSUGREEN.BITNET (SHOOU-YU TANG,PHYSICS DEPT,CSU,303-491-6372) writes: > After install the TOS 1.4 ROM into my 1040ST the ST display faster but it seem > might has a bug in the Desktop show info. > problem : When hightlighted either drive D or drive E of my 65MB hard drive and > chioce SHOW INFO from the desktop to see how much space left. After the hard > drive spin a while, an error box show up saying "This application cannot find > the folder or file you just tried to access". Yet it works prefectly with > drive C. And the old TOS has no problem with any drive. Some General observarions on TOS1.4 1. you done need foldrnnn at all with tos1.4. Its not supposed to be fatal, but you'll do better without it. 2. I found that it is absolutely necessary to REMOVE desktop.inf and reboot before doing a save desktop. There are incompatibilities between how 1.1 organized it and 1.4. Assuming that you do not have a Supre/ICD problem in their drivers I recommend 2. Howard C. Johnson ATT Bell Labs att!lzaz!hcj hcj@lzaz.att.com
VBRANDT@DBNUAMA1.BITNET (09/12/89)
In Info-Atari16 Digest #454, SYTANG%CSUGREEN.BITNET@Forsythe.Stanford.EDU asks: >... And the old TOS has no problem with any drive. >Is this cause by the TOS or the hard drive driver from ICD ? >equiptment: >1040ST, ICD adaptor, Adaptec 4070 controller and Seagate 277R 65MB RLL hard >drive, ICD Auto boot 2.1 , ICD hard drive driver 2.0 , Fold100 ... - Check that you *really* have TOS 1.4 as of April 6, 1989. - Use a newer version of the ICD driver, such as V4.31. - You don't have to use FOLDR100 with the new TOS 1.4, unless you want to access hundreds of folders in the same 'session'. I hope this helps. BTW: There is a new version of the ICD driver (V4.0) available on Compuserve, it's supposedly in 'public beta test'. I'd appreciate a copy VERY MUCH. Thanks !! ---------------------------------------------------------------------------- Bitnet: VBRANDT@DBNUAMA1 (will go away late '89) Volker A. Brandt UNM409@DBNRHRZ1 (soon) Angewandte Mathematik UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt (Bonn, West Germany) ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU
apratt@atari.UUCP (Allan Pratt) (09/13/89)
VBRANDT@DBNUAMA1.BITNET writes: >SYTANG%CSUGREEN.BITNET@Forsythe.Stanford.EDU asks: > - You don't have to use FOLDR100 with the new TOS 1.4, unless you want to > access hundreds of folders in the same 'session'. I have to jump on this one: you don't need FOLDR100 unless you access hundreds of folders AT THE SAME TIME. When you open a file, the directories from the root of that drive down to that file are "in use." When you close the file, they're not "in use" any more, and the space is reclaimed. Better internal memory management like this, and some other things (like way faster FAT code and program launching), is why you should get TOS 1.4 in the first place. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
kbad@atari.UUCP (Ken Badertscher) (09/15/89)
hcj@lzaz.ATT.COM (HC Johnson) writes: | 2. I found that it is absolutely necessary to REMOVE desktop.inf and reboot | before doing a save desktop. There are incompatibilities between how 1.1 | organized it and 1.4. There should be no incompatibility between the Rainbow TOS DESKTOP.INF file and those created with previous versions of TOS. If you're having a problem, please let us know the details. The DESKTOP.INF files should be completely interchangable, with the obvious exception that DESKTOP.INF files created with Rainbow TOS which have auto-launch files won't cause an auto-launch with an older TOS version. -- ||| Ken Badertscher (ames!atari!kbad) ||| Atari R&D System Software Engine / | \ #include <disclaimer>
Xorg@cup.portal.com (Peter Ted Szymonik) (09/17/89)
My experience has shown that the first thing to do after getting TOS 1.4 installed is REFORMAT the HD. My system was exteremely flaky after the upgrade until I reformatted - that should take care of ALL file not found errors. I am also pleased to announce that ALL of my previous problems with the TOS 1.4 upgrade are now in the dustbin of history!! I HIGHLY recommend the upgrade. Peter Szymonik Xorg@cup.portal.com
Xorg@cup.portal.com (Peter Ted Szymonik) (09/17/89)
Important Note: The latest official ICD software is 3.41, not 4.31!
Version 4.0.4 of the boot program is now up on CIS and GEnie
and the newest full software package should be up
soon - I think its 4.0.
Thanx
Peter Szymonik
Xorg@cup.portal.combammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) (09/18/89)
In article <22217@cup.portal.com>, Xorg@cup (Peter Ted Szymonik) writes: >My experience has shown that the first thing to do after getting TOS 1.4 >installed is REFORMAT the HD. My system was exteremely flaky after the >upgrade until I reformatted - that should take care of ALL file not found >errors. This is **NOT** true at all. I have gone though 3 generations of Tos 1.4 releases (developers disk based Tos 1.4, the ~feb eprom one, and now the real one) without re-formatting anything. heck one of the drives i am still using was formatted pre-mega-tos, and still has'nt given me a single problem. -- bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
woodside@ttidca.TTI.COM (George Woodside) (09/18/89)
In article <597@cwjcc.CWRU.Edu> bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) writes: ...[edited]... >... I have gone though 3 generations of Tos 1.4 >releases (developers disk based Tos 1.4, the ~feb eprom one, and now >the real one) The $64,000 question (I suspect I'm not the only one who wonders): Did you do a comparison between the developer EPROM release and the "real" one? Are they indeed the same? -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside
bammi@dsrgsun.ces.cwru.edu (Jwahar R. Bammi) (09/19/89)
In article <6214@ttidca.TTI.COM>, woodside@ttidca (George Woodside) writes: >The $64,000 question (I suspect I'm not the only one who wonders): > >Did you do a comparison between the developer EPROM release and the >"real" one? Are they indeed the same? >-- there are differences between the feb eprom version and the final TOS 1.4 there are **supposed** to be no differences between the developers Tos 1.4 roms (that is what i have, and despite all their denials, atari shipped me eproms and not roms, but i am not complaining), and the production Tos 1.4. my $68K question is has anyone received the Tos 1.4 docs. when we were purchased the developers Tos 1.4 final release, we filled all kinds of questionares and forms, and were promised the release notes in exchange for them. this was a few months ago. BTW: will someone from atari please tell us who designed the Spf<whatever> 68881 hardware interface? I would like to send some flames his/her way for not using their brains. -- bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
tom@buengc.BU.EDU (Prof. Thomas P. Skinner) (09/23/89)
I recently installed the new TOS 1.4 ROM chips. Upon attempting to use HDX.PRG I found it would not work. It knows about drive 0 all right, but never displays the partition dialog. It just returns to menu level. One other interesting item is that clicking on AHDI.PRG come back with a ROM version error. However, it seems to work OK. This is the only problem I have had with 1.4 so far. Is HDX checking the ROM version? I have tried three versions of HDX including 2.0 and the all fail. I am using a straight 1040ST and SH204 drive. I would appreciate a confirmation of this problem or comment from kbad@atari. Thanks.
jeff@onion.pdx.com (Jeff Beadles) (10/09/90)
I've been seeing a strange thing with TOS lately. When I try to drag a directory containing a directory called ".bak" to the trashcan, I get a message: "Invalid copy operation". To duplicate it: (I'm doing this thru GEM, but I'll give unix-like commands :-) cd c\ mkdir junk cd junk mkdir .jnk cd c\ Now, try dragging the folder "junk" to the trashcan... Is this a bug, or something that isn't legal? On a honest-ta-goodness-IBM-like-ms-dos-machine, it doesn't allow ".jnk" to be created... If you cd \junk, you can drag ".jnk" to the trashcan with no problems. Comments? Is there a "formal" way to submit a bug report to Atari? -Jeff -- Jeff Beadles jeff@onion.pdx.com -
alex@hpgnd.HP.COM (Alexis MERMET-GRANDFILLES) (10/16/90)
You cannot remove a folder if it is not empty. So , in your case , the folder junk contains the folder .jnk so you cannot remove junk until you remove .jnk first.
jeff@onion.pdx.com (Jeff Beadles) (10/19/90)
In <4280016@hpgnd.HP.COM> alex@hpgnd.HP.COM (Alexis MERMET-GRANDFILLES) writes: >You cannot remove a folder if it is not empty. > >So , in your case , the folder junk contains the folder .jnk so you cannot >remove junk until you remove .jnk first. Bleep! Wrong answer! Have you ever dragged (drug? :-) a folder to the trashcan that was not empty? I do it all of the time, and it work just fine as long as there isn't a folder called ".xxx" in it. To refresh people's memory, there's a bug with TOS1.4 that will not allow you to drag a folder to the trashcan and delete the files if there is a folder in the folder that starts with a "." (ie: .jnk) -Jeff -- Jeff Beadles jeff@onion.pdx.com
krueger@platon.fmi.uni-passau.de (Robert Krueger) (10/22/90)
[ problem: TOS 1.4 can't delete folders with files in it,
having a name like '.XXX' ]
I've done a lot of tests with creating and deleting folders and files,
and it seems to be as follows:
When TOS finds a filename of the type ' .XXX', then
it thinks of the file as being write-protected. So, if such a file
is inside a folder, TOS can't delete it and thus it can't delete
the folder also. In this case, the Desktop reacts with the
(somewhat missleading) errormessage "illegal copy-command"
(I hope, that's the msg. of the English TOS, because I only
know the German msg., saying: "Illegale Kopieranweisung").
Actually, the only fix I know is: Simply avoid filenames like '.XXX' !
OK, hope that helps !
--
>>> krueger@platon.fmi.uni-passau.de <<<hofer@urz.unibas.ch (Remo Hofer) (10/24/90)
In article <1990Oct22.132759.16881@forwiss.uni-passau.de>, krueger@platon.fmi.uni-passau.de (Robert Krueger) writes: > [ problem: TOS 1.4 can't delete folders with files in it, > having a name like '.XXX' ] > I've done a lot of tests with creating and deleting folders and files, > and it seems to be as follows: > When TOS finds a filename of the type ' .XXX', then > it thinks of the file as being write-protected. So, if such a file Since GEMDOS doesn't let you delete a folder which is not empty, the desktop has to delete all files and folders which are in the folder, if you drag a folder to the trash. Is it possible, that the desktop tests all folders, it finds in this folder, if their first char is a '.' to recognise the pseudo directory entries '.' and '..', which should not be deleted. If the desktop checks only the first char, it is not able to distinguish between a pseudo directory and a directory like '.XXX'. Any comments? Remo Hofer <hofer@urz.unibas.ch>
lincoln@cbnewsc.att.com (charles.e.lincoln) (05/23/91)
I've not seen anyone else describe this problem, but it started for me after I installed TOS 1.4 on my 1040ST. Every now and then when I double-click on a GEM application, instead of running it, the desktop gives me the show/print/cancel dialog box. When I click on cancel and double click on the application again, it always runs normally the second time. I haven't been able to detect any pattern as to when this happens, but I'm reasonably certain it's not the result of clicking on the wrong file. I would estimate it happens 5-10% of the time, and it can happen with any .PRG program (I haven't noticed it with .TOS or .TTP programs). Has anyone else observed this? Any solutions? If no one else has encountered it, I'll start ripping stuff out of my auto file to see if I can find the culprit. Chuck Lincoln lincoln@ihlpf.att.com
ekrimen@ecst.csuchico.edu (Ed Krimen) (05/24/91)
In article <1991May23.154113.24096@cbnewsc.att.com> lincoln@cbnewsc.att.com (charles.e.lincoln) writes: >I've not seen anyone else describe this problem, but it started >for me after I installed TOS 1.4 on my 1040ST. > >Every now and then when I double-click on a GEM application, >instead of running it, the desktop gives me the show/print/cancel >dialog box. When I click on cancel and double click on the >application again, it always runs normally the second time. >I haven't been able to detect any pattern as to when this >happens, but I'm reasonably certain it's not the result of >clicking on the wrong file. I would estimate it happens >5-10% of the time, and it can happen with any .PRG program >(I haven't noticed it with .TOS or .TTP programs). > >Has anyone else observed this? Any solutions? If no one else >has encountered it, I'll start ripping stuff out of my auto >file to see if I can find the culprit. This was one of the noted bugs in TOS 1.6 when the STe came out. This is the first time I've heard about it on TOS 1.4. People suspected that this was caused using an old DESKTOP.INF with the new TOS. This hasn't worked because this bug occurred for me several times when I ran GEM-View as a program. The theory in the beginning was that this bug was caused when an application with a short filename was executed; however, GEMVIEW.PRG isn't short. Also, an almost assured way to crash TOS 1.6: 1. At the desktop, set up a directory window showing the files in text mode; resize the window so that only the filename and size are showing. Position this window on the left side of the screen. 2. Select a text file and SHOW it. Use the right mouse button to exit, and hold it down when the computer redraws the desktop. 3. While the desktop is redrawing the scroll bar for the directory window, it seems that it gets confused with it and the right mouse button, which just happens to be on top of the scroll bar. I haven't done this in a while. You may have to move the mouse while holding down the right mouse button to get it to crash. Actually, I think it may reboot. -- ||| Ed Krimen [ekrimen@ecst.csuchico.edu or al661@cleveland.freenet.edu] ||| Video Production Major, California State University, Chico / | \ SysOp, Fuji BBS: 916-894-1261 "I AM OUTTA HERE!!!" -
stephen@oahu.cs.ucla.edu (Steve Whitney) (05/25/91)
In article <1991May23.154113.24096@cbnewsc.att.com> lincoln@cbnewsc.att.com (charles.e.lincoln) writes: >I've not seen anyone else describe this problem, but it started >for me after I installed TOS 1.4 on my 1040ST. > >Every now and then when I double-click on a GEM application, >instead of running it, the desktop gives me the show/print/cancel >dialog box. When I click on cancel and double click on the >application again, it always runs normally the second time. ... > At least in TOS 1.6, this happens with files that have an 18 character path name, I think. I only get it for E:\MWC\BIN\MSH.PRG... You can very nearly eliminate it (if not entirely) by changing names that happen to be that length. Pretty annoying. I have yet to hear any comments from Atari on it so I don't believe it's been fixed in later TOSses. >Chuck Lincoln >lincoln@ihlpf.att.com -- Steve Whitney - UCLA CS Grad Student (())_-_(()) Soon to be working at Silicon Graphics | (* *) | Internet: stephen@cs.ucla.edu UCLA Bruin--> { \_@_/ } GEnie: S.WHITNEY `-----'
steveh@tharr.UUCP (Steve Hebditch) (05/25/91)
In article <1991May23.154113.24096@cbnewsc.att.com> lincoln@cbnewsc.att.com (charles.e.lincoln) writes: >Every now and then when I double-click on a GEM application, >instead of running it, the desktop gives me the show/print/cancel >dialog box. When I click on cancel and double click on the >application again, it always runs normally the second time. There's a bug in the TOS 1.4 desktop that I've come across which prevents installed programs from running properly when the full name is 30 characters long. e.g. I've got Tempus installed so that clicking on any .MOD extender file runs it with that file. However, clicking on 'f:\modula2.sys\def\tqm\ vdi.mod' just gives the Show / Print / Cancel dialog instead. -- --- steveh%tharr.uucp@ukc.ac.uk Freebie usenet & 13 megs of Atari sox ---- ...ukc!axion!tharr!steveh Tharr: 0234 841503 -----