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

[Chris Withers]

Tim Peters wrote:
> [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

Does 2>&1 work on windows?

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

That seems consistent.

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

Yup, but it's pretty essential when the tests _are_ running fine or you get 
mile-long emails just to tell you everything is okay ;-)

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

Hmmm... is there not something that could be done at the C level in python's 
fiel deletion code that closes the file before it's deleted?

> 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

Hmmm... I appear to be lacking in Zen, how would one go about investigating 
whether or not this was the problem?

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

Wagh :-(

Hmmm... did this code always exhibit these problems under this version of python 
or has there been a code chaneg that started triggering it?

cheers,

Chris