Windows file locking causes Environment unit tests to fail

[Ian Leader <__ian.leader__@…>]

Windows XP SP2, Python 2.3.4, sqlite 3.2.1

On above environment, as of [1739] two unit tests in env.py error because they cannot clean up the database file created in the temporary environment:

C:\temp\working\trac>python trac\tests\env.py
EE
======================================================================
ERROR: Testing env.get_known_users
----------------------------------------------------------------------
Traceback (most recent call last):
  File "trac\tests\env.py", line 19, in tearDown
    shutil.rmtree(self.env.path)
  File "C:\Python23\lib\shutil.py", line 140, in rmtree
    raise exc[0], (exc[1][0], exc[1][1] + ' removing '+arg)
OSError: [Errno 13] Permission denied removing c:\docume~1\ianlea~2\locals~1\tem
p\trac-tempenv\db\trac.db

======================================================================
ERROR: Testing env.get_version
----------------------------------------------------------------------
Traceback (most recent call last):
  File "trac\tests\env.py", line 14, in setUp
    self.env = Environment(env_path, create=True, db_str='sqlite:db/trac.db')
  File "C:\temp\working\trac\trac\env.py", line 56, in __init__
    self.create(db_str)
  File "C:\temp\working\trac\trac\env.py", line 114, in create
    os.mkdir(self.path)
OSError: [Errno 17] File exists: 'c:\\docume~1\\ianlea~2\\locals~1\\temp\\trac-t
empenv'

----------------------------------------------------------------------
Ran 2 tests in 0.781s

FAILED (errors=2)

C:\temp\working\trac>

(when running the full unit test suite, this then causes knock-on errors in attachment unit test cases because the temporary environment already exists)

I think this is occuring because the Environment creates a database connection pool, and the connections in the pool are not closed during tear down. Therefore file locking or R/W files in Windows prevents the tear down from cleaning up.

I'm not sure of the best way to tackle this. Three options spring to mind:

1. Use an InMemoryEnvironment (would this still be a valid test if you are not creating a real environment?)
2. Create a method to close down the connection pool (as this does not appear to exist, and is therefore not used for real, is it appropriate to add this code to the system just for testing?)
3. Something else…

[Christian Boos]

I noticed that too this W.-E. I'll try to fix it asap.

[Christian Boos]

Got no better idea than 2. … Thanks for the suggestion (fixed in [1740])