🚀 go-pugleaf

>   The Fcreate() problem is a difficult one to pin down.

Yes.

> Occasionally it would create two files
> with the same name in a single directory.

I found out why: in GEMDOS, Fcreate calls Fdelete, but doesn't check to see
if the delete actually worked.  If the delete fails for some reason, Fcreate
doesn't notice, and creates another file by the same name.

> I implemented a creat() call in dLibs which always
> deletes the file before creating it[.]

This won't help, because if Fcreate's call to Fdelete fails, yours will too.

> Since Fdelete() is relatively quick and Fcreat() is quite slow [...]

Fcreate is not slow.  The first write to the file after Fcreate is slow. 
This is because the code which looks for the first free cluster on the
device is slow.  This is especially noticable for large, nearly-full
devices.  We are addressing this problem.

Now here's the tricky part:  Fdelete (as called from outside GEMDOS or
within it, like from Fcreate) checks to see if anybody has the file open.
If the current process has the file open, Fdelete closes it before deleting
it.  If some OTHER process has the file open, Fdelete returns EACCDN
("access denied").  This seems to be what is happening, but I can't
figure out why, because nobody else has the file open!

I can always reproduce this problem.  Here's how:

	Proc1:
	------
	Fcreate ("file1",0);
	Fcreate ("file2",0);
	Pexec(4,"Proc2",0L,0L);

				Proc2:
				------
				Fdelete("file1",0);
				/* returns EACCDN: Proc1 has file open */

				Fcreate("file2",0);
				/* works, even though it should fail */

				Pterm0();
	Pterm0();

Now there are two copies of "file2" in the current directory, even though
the failed Fdelete of "file1" in Proc2 shows that GEMDOS is checking for
file ownership.

I can't figure out why this happens in Emacs so much, but it happens. 
If you fix Fcreate so it does check the return code from Fdelete and
returns EACCDN, Emacs will tell you it can't open the file for writing. 
This is more correct behavior than creating two files, but still doesn't
explain why Fdelete thinks somebody else has the file open when nobody
else does. 

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