STZIP

[ekl@sdf.lonestar.org (Evan K. Langlois)]

There were 2 problems I was having with STZIP that I was sure were MiNTs
fault, and from the testing I was able to do I was pretty sure.

Anyway, now I have a VT240 terminal connected so I can watch MiNTs trace
output and pause it and such without wasting paper or cluttering my screen.
>From its output I was able to check things and found that MiNT returned 
a -33 and not a -34 when a path/file has a path that does not exist (when
a pathname is not found).

However, this was only for loaded file systems.  How can loaded file systems
tell if the name being passed (to the "lookup" function) is supposed to
be a directory or a filename?  I couldn't find out, so I kludged MiNT.

In relpath2cookie, where its parsing the path/filename (I left the FS_KNOPARSE
or whatever alone since the filesystem should return the correct value), 
and right after the look_up function is called I added :

  if ((r == EFILNF) && (*path))
	r = EPTHNF;

This makes the assumption that if there is more path to parse, and the lookup
function said "file not found", what it must have meant was "Path Not Found"
since we must have passed a directory name to it instead of a filename.

That makes STZIP create folders on loaded filesystems (and likely fixes a
few other programs since the return codes are now GEMDOS compatible or closer
to it anyway).  The other problem was not being able to read a ZIP file on
 a RAMFS system.  Changing the ram_seek function in ramfs.c fixed that (it
used minus instead of adding the negative thing that everyone talked about
before).

I also added all the other diffs that I collected (from what I had).  When
is 1.10 coming out?  Oh .. I'll send a diff later if anyone wants it - I
just don't have DIFF on my drive (accidently deleted it and a few other 
goodies).

Has anyone worked on the blocking fork() problem or the blocking IO (or rather
system locking IO) ??

CYA
EKL