🚀 go-pugleaf

> Submitted-by: madsen@sask.usask.ca (Jorgen Madsen)
> Posting-number: Volume 3, Issue 52
> Archive-name: mx2v230/part01

This multi-tasking system was submitted to comp.binaries.atari.st and
comp.sources.atari.st...  I have been looking at the program which gives
one ST remote access to the other's disk drives. 

Until I look a little further, my advice is this: DO NOT USE THIS PROGRAM!  
I am talking about the network file system part of the MX distribution:
the rest, for all I know, works fine.

The problem with the networking part is this: it changes the contents of
the disk without GEMDOS's knowledge.  This can be disasterous if the
program changes a disk block which GEMDOS has in memory.  There is no
(legal) way to know if GEMDOS has a block cached, and even less of a way
to tell GEMDOS that a block is suddenly changed, and it's even WORSE
when GEMDOS has a block cached AND HAS CHANGED THE CACHED IMAGE (that
is, the cached block is "dirty"). 

If you use the networking for reading only, or if you are EXTREMELY
careful about how you use it, you can succeed.  By being careful, I mean
that the person using the ST locally and the one using it remotely
should never access the same logical drive.  I don't mean not accessing
it at the same time: I mean accessing it EVER. 

If you restrict both users to read-only access to a logical drive,
you'll do okay.  So if you both access drive E: for reading only, and
one of you accesses drive D: for reading and writing, and the other one
accesses drive F: for reading and writing, you should do OK. 

If you want a detailed disaster scenario, here it is:

	User L is local, user R is remote, and mx2net is running on both
machines. 

	User L begins editing D:\SRC\FILE1.C.  GEMDOS caches part of the
FAT from drive D:. 

	User R begins D:\WORK\FILE2.C (that's D: on L's system).  *His*
GEMDOS also caches part of the FAT from drive D:. 

	User L writes his edited file to disk.  It got bigger, so a new
cluster is allocated.  The new FAT is written to disk. 

	User R writes *his* edited file to disk.  It got bigger, too, so
a new cluster is allocated.  But User R's GEMDOS uses the cached FAT
from drive D: to allocate the new cluster, and allocates the same one!

BAD NEWS.  It can get worse, too.  Notice that it doesn't matter that
they aren't accessing the same folder, and it doesn't matter if they
don't do it at the same time: the problem is that user R has an
out-of-date local copy of a sector on drive D:, and his GEMDOS can't
know it. 

But if all the drives they both use are read-only, then they can each
use other drives for read/write and never get into trouble. 

This is not as much of a problem under TOS 1.0 or 1.2, because GEMDOS is
really stupid about invalidating perfectly clean, cached sectors, but
TOS 1.4 is *not* stupid about it, and it is really easy to get bitten by
this.  It's still possible under TOS 1.0 or 1.2, however. 

I applaud the effort which the author has clearly put into this.  I have
not tried, let alone analyzed, the multitasking part.  I hope he has not
fallen into the same local-copy-of-global-data trap.  Has anyone out
there had experience with the previous versions of this code?

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt