[comp.sys.atari.st] TOS problem ?

piet@cs.ruu.nl (Piet van Oostrum) (10/15/89)

I encountered a strange TOS behaviour (TOS 1.2):

I Fcreate a file, then Fopen the same file (not very usual, I agree). I get
two filehandles of course. I only use the second one, and write some bytes
to the file. Finally I close the second handle, and forget to close the
first one, (or close that last). Result: an empty file. If the first
filehandle is closed first, no problem.

My guess is that the close on the first filehandle (either implicit or
explicit) remembers that nothing has been written on this handle, so the
file should be empty (???)

Note: the compiler has long ints (GCC).

Any comments? Is this a bug? Here is the program:

------------------------------------------------------------------------
#include <osbind.h>
char fname[] = "test.fil";
char message[] = "this is a line\n";
main()
{
	int fd1, fd2, r;
	
	fd1 = Fcreate(fname, 0);
	fd2 = Fopen(fname, 1);
	r = Fwrite(fd2, strlen(message), message);
	printf ("fd1=%d,fd2=%d,result=%d\n",fd1,fd2,r);
	Fclose (fd2);
	Fclose (fd1); /* or just delete this line */
}
-------------------------------------------------------------------------- 
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht,  The Netherlands.
Telephone: +31-30-531806      Internet: piet@cs.ruu.nl
Telefax:   +31-30-513791      Uucp: uunet!mcsun!hp4nl!ruuinf!piet

apratt@atari.UUCP (Allan Pratt) (10/17/89)

piet@cs.ruu.nl (Piet van Oostrum) writes:

>I encountered a strange TOS behaviour (TOS 1.2):
>I Fcreate a file, then Fopen the same file (not very usual, I agree).
>... Finally I close the second handle, and forget to close the
>first one, (or close that last). Result: an empty file. 

Well, that's interesting, but only just.  Opening the same file
twice is something which GEMDOS doesn't handle well (pun intended).

I can apologize for only so long for how bad GEMDOS is before the 
blame shifts from the guy who wrote it (for introducing the bugs) to me
(for not fixing them).  I hope I haven't gotten to that point yet.

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