tlz@drutx.UUCP (04/07/87)
I knew it was too good to be true, but I'm ALWAYS overly optomistic... I put GEMBOOT on my 20 Meg Supra system last week, turned on the power, got a "logging in drive c:" message and sat back while it ate my disk. Ten minutes later (I was catatonic and couldn't reach the reset button), it finished. I looked... there were 9857 files containing 123231206769813 bytes...files like 174Y$&*%$(*%Q(@ and ()*)(&$(#*^ and such ...geeez, I've seen this before! Oh, well, I said, I'll just get the old backup disks and start over. Tried it again and everything seemed fine..until last Sunday. Here's the scenerio. I turn on the system and everything boots fine. All 62 folders are "logged in". Copy a few files from A: to C:\TEMP\. Go have a little bite to eat and watch the tube, so off goes the system. A little later, I turn on the system and it starts "logging in drive c:" for a LONG, AGONIZING time. This time I was not dazed, just extremely upset, so I hit reset. The files in C: suffered the same sort of damage as before. In addition, the boot sector was damaged. After spending 4-5 hours rebuilding things and trying to re-establish the Supra v2.61 autoboot function, I gave up and called Supra. "Yes", they said. "GEMBOOT is bad. Trashes your disk. Don't use it. Actually DECREASES your available folders to 20." "And here's how to reformat your boot sector. Start formatting the hard drive, wait a few seconds after is says 'please wait, etc' and turn the computer off. Boot from the floppy (which, hopefully, contains all the hard disk utilities) and reformat the hard disk again. This is the ONLY way to reformat a bad boot sector." Apparently, supfmt.prg reads the boot sector, zeros it, formats the disk and finally writes the data back onto the boot sector. When you kill it in the middle, the sector is left zeroed, forcing it to reformat when the disk is reformatted. Isn't this exciting? I don't know why this is happening. Probably some bizzare, intertwined series of dependencies like certain accessories and/or AUTO\*.prg files. Maybe a subtle bug in GEMBOOT. Maybe both or none. I don't care. I just wanna use my computer. *** FLAME ON *** THIS is why Atari doesn't distribute things to the public that they aren't 100% convinced works correctly. Its bad enough as it is that some of us with access to USENET get burned, let alone the rest of the ST world. For my part, I've done my civic duty. I took a chance. I lost. If any more "fixes" come around, I'll put them in after a few hundred others and a few months go by. *** FLAME OFF *** I want new ROMs. OK, Neil? Terry Zrust @ AT&T Informations Systems Laboratories Denver, CO.
engst@batcomputer.tn.cornell.edu (Adam C. Engst) (04/08/87)
Has anyone else had documented (or any other) problems with GEMBOOT? I just
installed it on the Cornell ST Users Group PD Hardisk and I would really not
want to recopy all that data again if it ate the disk. The only other
program I have in the auto folder is M-disk (renamed to amdisk to access
before Gemboot) and there aren't any accessories. Should I remove GEMBOOT
or what? That is the question, as I see it. Konrad?????
Adam Engst
engst@batcomputer.tn.cornell.edujohn@viper.UUCP (04/13/87)
In article <10157@cgl.ucsf.EDU> pett@socrates.ucsf.edu.UUCP (Eric F. Pettersen) writes: >In article <634@batcomputer.tn.cornell.edu> >engst@tcgould.tn.cornell.edu.UUCP (Adam C. Engst) writes: >> >> .... The only other >>program I have in the auto folder is M-disk (renamed to amdisk to access >>before Gemboot) .... > >The programs in *any* folder are *not* accessed in alphabetical order. They >are accessed in the order they were originally placed in the folder. It is >important to know this if, say, you are trying to list the files in a folder >alphabetically. > > Eric Pettersen > UCSF Computer Graphics Lab > pett@cgl.ucsf.edu or ucbvax!ucsfcgl!pett Close Eric, but you left of an importandt point which would easily allow someone to use your information and still get it wrong.... What Eric said is correct if-you-start-with-an-empty-folder... If the folder did have files in it, you went in and deleted one of them, and then added a file, the new file will probably take the place of the old file in the file-sequence. The method I use to reorganize a folder is: 1) Create a new empty folder on my ramdisk with the name of the folder I want to replace. 2) Leave the ramdisk folder closed... 3) Open the original folder. 4) Copy the files ONE-AT-A-TIME into the closed ram-folder 5) Delete the original folder 6) Click and drag the CLOSED(!) ramfolder to it's new home. (Many people don't quite understand how the ordering of files in an AUTO folder really works... Those that do often forget (or never knew) that when you drag a CLOSED folder, the files end up in the same "real" order as they were in the original...) --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
john@viper.UUCP (04/13/87)
For those of you who may not have an ST or for those who do and
are still confused:
The Gem Desktop utility sorts the displayed file lists into on of
four different sorting orders. There is no (known to me) way to shut
off the sorting. In most cases, none of the sortings display the
real order that the files lie on the disk. The AUTO folder contains
programs that are run at boot-up time. The AUTO programs are run in
"real" file order, not any of the sorted orderings...
This means that unless you are careful, you will have no control
over which boot programs are run first, 2nd,... last... The method I
gave in my previous message explains a method which will allow people
to -exactly- order the sequence of auto programs.
The "trick" is that while files in an open folder (where the directory
is displayed) when copied end up in the sorted order, when you copy a
closed folder, the files end up in the same order they're "really" in
because the desktop doesn't sort the contents of a closed folder....
---
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!johnjohn@viper.UUCP (04/13/87)
BTW, Neil,
Any chance we can get an addition to the new (coming "real-soon-now")
desktop for a 5th sorting option? Namely -un-sorted.... This would
take a -very- small change in the desktop code, would take almost no
extra code space (one new line on the menu bar and about 10 lines of
code), and it would go a long way twords solving the Auto folder problems
that many people are having...
And in case you were wondering, the answer is "Yes, this is a problem".
(I've had to explain this exact thing to more than 25 people in the last
5 months...) The documentation provided with the ST is VERY misleading
on this issue. It implys that files will always be executed in sorted
order... (Alphabetical order to be precise). When the files -ae-
executed in alphabetical order, it's only by accident and further
misleads the user into thinking this is the way hings are done.
The files are, in fact, executed in "real" disk-order which the
joe-average user currently has no way of checking...
---
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!johnneil@atari.UUCP (04/17/87)
In article <831@viper.UUCP>, john@viper.UUCP (John Stanley) writes: > BTW, Neil, > Any chance we can get an addition to the new (coming "real-soon-now") > desktop for a 5th sorting option? Namely -un-sorted.... 1. What new desktop? The only change in the new ROMs is the addition of a new choice on a menu for disabling the blitter chip. 2. I agree that an unsorted list of files is a heckuva good idea. Have you looked at the DCOPY shareware utility that is floating around (its on Atari Base and GEnie, among other places). -- --->Neil Harris, Director of Marketing Communications, Atari Corporation UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil GEnie: NHARRIS/ WELL: neil / BIX: neilharris / Delphi: NEILHARRIS CIS: 70007,1135 / Atari BBS 408-745-5308 / Usually the OFFICIAL Atari opinion