Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!evax!cs4344af From: cs4344af@evax.arl.utexas.edu (Fuzzy Fox) Newsgroups: comp.sys.cbm Subject: Re: Validating GEOS disks (Was: Downloading GEOS files) Message-ID: <1991Mar30.044950.3816@evax.arl.utexas.edu> Date: 30 Mar 91 04:49:50 GMT References: <20097@brahms.udel.edu> <1991Mar29.194707.15835@evax.arl.utexas.edu> <1991Mar30.021857.22494@alchemy.chem.utoronto.ca> Organization: Computer Science Engineering Univ. of Texas at Arlington Lines: 49 In article <1991Mar30.021857.22494@alchemy.chem.utoronto.ca> mroussel@alchemy.chem.utoronto.ca (Marc Roussel) writes: > > <> Wrong! When people who use this game-show oriented phrase it really pisses me off, so forgive me if I flame you back. > GEOS files are indeed USR files, but that's not the part that >confuses Commodore DOS. (USR files are just glorified SEQ files. Why >GEOS chose to use the USR designation, rather than SEQ or PRG, we can >only speculate.) This is not right. It is true that Commodore DOS treats USR files like SEQ, but GEOS has invented a new filetype which is nothing like REL or SEQ, and it is called VLIR. Many data files, such as GeoWrite or GeoPaint, are in this format. A normal SEQ file has pointers to just the first data block, and that block points to the next, and so on. DOS treats USR files like this, too. A VLIR file from GEOS has 2 pointers, one to the header block and icon block, and another pointer to the record block. The record block, in turn, has pointers to 127 other records. Essentially, this block is a list of track/sector pointers, and DOS does not understand that at all, so if you validate with DOS, all of the actual data stored in a VLIR file will be de-allocated, resulting in tragedy later on. Furthermore, under GEOS, VLIR or SEQ files both have an icon block stored with the file, and DOS will free that up under validate, too. Next time you write to the disk, LOTS of data will get written over, and you probably won't even be able to open the disk anymore. >The reason you should never validate a GEOS disk >outside of GEOS is that Commodore DOS doesn't know about the border blocks. >GEOS needs a way to keep track of files on the desktop's border. This is also true, but it is not even close to the whole story. Of course, even if this were the only problem, a trashed out border block would still render the disk unopenable, and thus useless under GEOS. If you accidentally validate a GEOS disk, immediately go into GEOS and validate it there, to prevent losing any data. -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---