[Zope-Coders] Win32 Tests - Zope HEAD - Not OK :-(

[Tim Peters]

[Tim]
>> Exactly how is it that these tests get run?  I don't see
>> ignored execptions.  I ran these tests, under the same 2.2.2, just now,
>> on the Zope HEAD, on Win98SE, via
>>
>> C:\Code\Zope>\python22\python utilities\testrunner.py -a -v2

[Chris Withers]
> Well, this is on Win2K.

That appears relevant, too.  I tried it on Win2K, via

C:\Code\Zope>\python22\python utilities/testrunner.py -v2 -a > out.txt 2>&1

and out.txt contained one line w/ this stuff:

...
checkReconnectFallback (testConnection.FileStorageReconnectionTests) ... ok
checkReconnectReadOnly (testConnection.FileStorageReconnectionTests) ...
Exception exceptions.OSError: (13, 'Permission denied',
'C:\\DOCUME~1\\ADMINI~1\\LOCALS~1\\Temp\\~296-138.inv') in <bound method
TemporaryFileWrapper.__del__ of <closed file
'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\~296-138.inv', mode 'w+b' at
0x02985DC8>> ignored
ok
checkReconnectSwitch (testConnection.FileStorageReconnectionTests) ... ok
...

> The command line would be:
>
> D:\ZopeTests\sandbox\Zope>c:\python22\python
> utilities/testrunner.py -v 0 -a

With -v0 you can never know which test triggered it, right?

> This is run from a popen3 in autotester.py (see
> cvs.zope.org/Packages/TestScripts) which is triggered by a batch script
> triggered from the Scheduled Task list.
>
> ...
>
> Well, can you suggest any possibilities that I can investigate?

checkReconnectReadOnly is apparently the culprit.  The business of not being
able to delete or rename open files is a deep and endless PITA on Windows.
In some cases it's due to file descriptors getting inherited across a spawn,
in which case it doesn't help if the parent process closes the file -- the
child still has it open, even if the child doesn't know it, so the parent
still can't remove it.  I don't know whether that's what's happening here,
but it's something to investigate

I made changes in Python 2.3 to ensure that temp files on Windows are not
inherited by spawned processes, but it's impossible to arrange for that
under Python 2.2 (it needs access to the MS-specific O_NOINHERIT flag, which
2.2 doesn't know anything about).

OTOH, if it were due to inheritance across spawning, I'd expect the same
error msg on Win98SE too.  The only thing unique to Win2K I know of is that
a file opened with the MS-specific O_TEMPORARY can't be opened a second
time, but that can't be the issue here because 2.2 doesn't know anything
about O_TEMPORARY either.