🚀 go-pugleaf

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

This WILL* help, because I check the return value from Fdelete() to be sure
that it succeeds.  The code is as follows (from the extended arg proposal):

/*
 * Create a new file <filename> with <pmode> permissions
 */
int creat(filename, pmode)
	register char *filename;
	register int pmode;
	{
	register int rv;

	rv = Fdelete(filename);
	if((rv == 0) || (rv == -33))    /* SUCCESS or FILE-NOT-FOUND */
		{
		if((rv = Fcreate(filename, pmode)) >= 0)
			iovector[rv] = 'F';
		}
	return(rv);
	}

> 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!

Yes.  In my implementation of creat(), any error except -33 (EFILNF) will
be returned without calling Fcreate().  Error code -36 (EACCDN) is therefore
returned if the file can't be deleted due to the Fcreate() bug.  In emacs,
this causes a file write error and you can then write the file out under a
different name, which is better than silently creating a duplicate.

                Dale Schumacher
                ..ihnp4!meccts!stag!syntel!dal
                (alias: Dalnefre')