Mail Archives: cygwin-developers/2000/03/18/01:35:55
On Fri, Mar 17, 2000 at 08:25:11PM -0500, John Fortin wrote:
>> Can someone take a look at the configure code that is failing, pare it down
>> to a simple test case and either report it here or, even better, run strace
>> on a failing shell and send it here?
>
>OK, here goes...
>
>I trimmed the failing configure script to this which still fails with
>this output:
>
>~/gnu/autoconf-2.13/: config.jef
>config.jef
>.//config.jef: cannot create temp file for here document: Permission
>denied
>~/gnu/autoconf-2.13/: bash -version
>bash -version
>GNU bash, version 2.03.0(2)-release (i686-pc-cygwin)
>Copyright 1998 Free Software Foundation, Inc.
>~/gnu/autoconf-2.13/:
I've checked in a change that seems to fix this. There is danger here,
however. I messed around with the unlink() function.
The problem was that bash was using a UNIX-idiom. It was opening a file,
deleting it, and then reading from it. Windows doesn't allow you to
delete an open file so cygwin works around this by maintaining a queue
of files to delete when it finds that it has hit a sharing violation
like this.
Windows 95, in certain circumstances, does not return a sharing
violation when an attempt is made to delete an open file. Instead, it
returns an access error. This makes the error indistinguishable from
other access errors.
So, I rewrote unlink() to open the file with a "CLOSE_ON_DELETE" flag
in cases where it couldn't delete the file immediately.
On NT, that will actually do exactly what we want. On 95, it may fail
but if the file is already open *then* I'll get a sharing error. So,
we can detect that and queue the file for later deletion -- the old
fashioned way.
Anyway, please, everybody test this and let me know if I've broken
anything.
Thanks, John, for the test case, and strace output that allowed me to
pinpoint the problem.
cgf
- Raw text -