Newsgroups: comp.sys.cbm
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!mroussel
From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
Subject: Validating GEOS disks (Was: Downloading GEOS files)
Message-ID: <1991Mar30.021857.22494@alchemy.chem.utoronto.ca>
Organization: Department of Chemistry, University of Toronto
References: <20097@brahms.udel.edu> <1991Mar29.194707.15835@evax.arl.utexas.edu>
Date: Sat, 30 Mar 1991 02:18:57 GMT

In article <1991Mar29.194707.15835@evax.arl.utexas.edu>
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) writes:
>GEOS files are supposed to be type USR, because they are formatted in a
>way that is rather alien to Commodore DOS.  This is why you should never
>validate a GEOS disk unless you are in GEOS.

<<Buzzzz>> Wrong!
     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.)  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.  When you
drag a file to the border, GEOS keeps track of this by creating an entry
in a dummy directory in some specially designated blocks.  (At that point,
the files have been taken out of the regular directory.)  To keep from
overwriting this border directory, GEOS allocates these blocks in the BAM at
format time.  There are however no actual files kept there, so when you use the
regular Commodore validate command on GEOS disks, it sees empty blocks and
deallocates them in the BAM.  GEOS' validate on the other hand knows about the
special meaning of these blocks and leaves them alone.

				Marc R. Roussel
                                mroussel@alchemy.chem.utoronto.ca