Re: two bugs fixed in ramfs 1.4

[Howard Chu <hyc@hanauma.jpl.nasa.gov>]

Howdy, all...

  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. ]

Well, lseek in Unix says the offset is added to the specified position
(beginning, current, end), so this would seem to be a pervasive bug.