JEMCCABE@MTUS5.BITNET (02/19/88)
Date: 18 February 1988, 12:35:09 EST From: Jim McCabe JEMCCABE at MTUS5 To: INFO-ATARI16 at SCORE.STANFORD.EDU Subject: GEMDOS bug (attn -- Alex) [] I have found an annoying bug in GEMDOS, and it occurs so frequently that I'm sure someone out there must know how to avoid it. In a disk-storage-intensive program I'm working on, it becomes advantageous to be able to swap disks after loading the program. (For example, one might load the program, then insert a data disk...) I've noticed that GEMDOS is consistantly unable to read in the new directory tree from the new disk. After swapping disks, my application has no trouble locating files in the root directory, but all attempts to open files that are in a subdirectory of the new disk fail with an error -33 (file not found). I asked this question before, back in October '87. Mike Fischer (fischer@yale.arpa) was the only one to respond, and his answer was: > One > fix is to use Fsfirst with a path in the root directory to force > GEMDOS to access the disk after the swap. Then you should be able > to follow that by an Fopen for the file you really wanted. Note > however that if you are not specifying the complete pathname (with > a "^" immediately after the ":"), then you are asking for a file > relative to the current working directory, which hasn't been resent. > If this is your problem, then you also need to set the working > directory after the disk swap. I tried his advice, and it doesn't work (at least not on _my_ ST). Here's the order I perform his fix: (psuedocode) dsetdrv(0); { Set current drive to drive A } dsetpath('A:^'); { Current working directory = "A:^" } fsfirst('A:^*.*', 0); { Read first file from root directory } fopen('A:^MESSAGES.BBS^BOARD30.MSG'); { I know the fopen syntax is wrong here, but ignore that } And it still can't find the file! Can anyone help me, please?!?!? Thanks! +-----------------------+--------------------+------------------+ | Jim McCabe | Bitnet | UUCP | | G31 ECH MTU | ---------- | -------- | | Houghton, MI 49931 | jemccabe @ mtus5 | mccabe @ m-net | +-----------------------+--------------------+------------------+
apratt@atari.UUCP (Allan Pratt) (02/20/88)
in article <8802190133.AA02942@ucbvax.Berkeley.EDU>, JEMCCABE@MTUS5.BITNET says: > I have found an annoying bug in GEMDOS, and it occurs so frequently > that I'm sure someone out there must know how to avoid it. > [Description of media-change-not-recognized bug follows.] We are aware of this problem and are fixing it. The problem happens mostly when the root directory, fat, etc. of the first disk are so short that they can all be cached -- There is code to check media-change to validate a cached buffer, but it seems it isn't being used as it should. The bug has to do with the fact that the directory-structure cache didn't check for media change, but assumed that its internal tree representation was still correct. We apologize for the inconvenience. The bug is fixed in the upcoming new ROMs. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
trb@stag.UUCP ( Todd Burkey ) (02/22/88)
In article <8802190133.AA02942@ucbvax.Berkeley.EDU> JEMCCABE@MTUS5.BITNET writes: >Date: 18 February 1988, 12:35:09 EST >From: Jim McCabe JEMCCABE at MTUS5 >To: INFO-ATARI16 at SCORE.STANFORD.EDU >Subject: GEMDOS bug (attn -- Alex) > >[] > >I have found an annoying bug in GEMDOS, and it occurs so frequently >that I'm sure someone out there must know how to avoid it. > >new disk. After swapping disks, my application has no trouble locating >files in the root directory, but all attempts to open files that are >in a subdirectory of the new disk fail with an error -33 (file not >found). > >I asked this question before, back in October '87. Mike Fischer I asked the same question a year ago when I was writing HDSCAN. Had the same problem, but since HDSCAN wasn't really intended to do much heavy work FROM the floppy, I decided to hold of on the workarounds. I tried LOTS of permutations with doing FSFIRST, etc. It would work sometimes, but not reliably. I just got through writing a new program that has to read the floppy subdirectories, but now I can't get the problem to pop up at all. I am using MWC 2.xx (I originally had the problem on MWC 1.x and OSS Pascal 1.xx both of which are dust now). The file open calls I am currently using to open the files for access are Fopen and fopen (don't ask...) and I do try to open a file at the root level (either a direct file or the volume name...doesn't matter) before any access to the sub-directories on the disk. This is one of those problems that makes it so fun when I port my code back and forth between the ST and Unix... -Todd Burkey (Yes, Jim S...DISKSCAN is now done and you really will get the first copy! And the TOOL-WARE version will be in the Snail Mail to those of you patient people who liked DISKTOP enough to send in $$. Note that I am hesitant to use the 'S' ware word on the net after all the strange arguments that pop up when people see it :-). Oh, BTW, DISKTOP is shelved until OSS Pascal 3.00, or whatever version, fixes the flakiness in 2.xx. I don't expect any future for DISKTOP with DISKSCAN available, anyway...)