Mail Archives: djgpp-workers/2000/05/27/02:38:56
--text follows this line--
> From: pavenis AT lanet DOT lv
> Date: Fri, 26 May 2000 20:18:53 +0200
>
> Let assume gcc tries to create file in TMPDIR=c:/tmp and directory
> with the same name already exist there. Then it gets EPERM
Sorry, I don't understand: EPERM should never be returned in DJGPP,
except for some very obscured network-related problems (see doserr2e.c
in the library). Perhaps you meant EACCES?
> That
> is rather unlikely as biostime() is used to generate first file name (and
> it's later incremented).
Where do you see the call to biostime? Is it something that GCC
sources do? I don't see biostime in mkstemp.
> In this case (BUG) it's assumed that directory is
> bad and it quits the loop. Function mkstemp() in libc also has this
> problem (if it gets EPERM it quits the loop)
But if the file or directory by that name exists, mktemp will see it,
because it calls __file_exists, and so it will never return a name of
an existing file. What you describe can only happen in a race
condition, when a directory is created *after* mktemp returned a name
of a file that didn't exist a moment before.
> Perhaps mkstemp should use stat() if it gets EPERM to verify whether
> file (or directory) exists and and only give up if it's doen't exist.
stat is too expensive. We could add EACCES to EEXIST, or we could
explicitly check with _chmod to cover the directory case.
In any case, I think GCC should not abort, but print an error message
in these cases.
- Raw text -