Re: two bugs fixed in ramfs 1.4

[bousch@suntopo.matups.fr (Thierry Bousch)]

Hello Evan,

> ========================  quote =======================
> You should apply the following patch to ramfs.c to upgrade it from
> version 1.4 to version 1.5.  It fixes these two bugs.
> =======================================================
> 
> I believe there is another bug.  STZIP Fseek's to the end of the
> file to read the header information at the end.  STZIP is not able
> to read the header information from any file on RAM FS.  I believe
> its a problem of RAMFS.

increasing the debug level in MiNT reveals that stzip issues a

    Fseek(-2048,2) on handle 6
    
which should hopefully put the pointer 2048 bytes before the end of the
file.  The problem is of course: should the offset really be negative? I
have two books about Gemdos which give two different answers to this
simple question -- probably Murphy's law. 

Most of the device drivers existing for MiNT (procfs.c, shmfs.c,
clockdev.c) assume that Fseek(offset,handle,2) will put the pointer
"offset" bytes _before_ the end of the file.  Therefore, "offset" should
be positive.  Ramfs also follows this convention.  Minixfs probably
follows the opposite convention, since it works with stzip. 

[ We could make the program more bomb-proof by considering only the
absolute magnitude of "offset"; but in ramfs you should also be able to
seek past the end of a file, so it's not desirable. ]

Thierry.