[ZCM] [ZC] 1693/ 4 Wontfix "ZODB: Strange interference with os.popen"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1693 Update (Wontfix) "ZODB: Strange interference with os.popen"
 Status Wontfix, Database/bug medium
To followup, visit:
  http://zope.org/Collectors/Zope/1693

==============================================================
= Wontfix - Entry #4 by tim_one on Feb 7, 2005 11:44 am

 Status: Accepted => Wontfix

OK, what's going on is exactly the same as in this snippet, which doesn't use ZODB:

>>> f = open('dummy.txt', 'w')
>>> import os
>>> p = os.popen(r'\bin\wc.exe', 'w')
>>> f.close()
>>> os.remove('dummy.txt')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OSError: [Errno 13] Permission denied: 'dummy.txt'
>>>

Two things feed into this:

1. A process spawned by os.popen() inherits descriptors
for all open files.

2. Windows does not allow deleting or renaming an open file.

#1 is true cross-platform; #2 is specific to Windows.  The consequence is that no file that was open at the time popen() was called can be deleted or renamed until the popen'ed process terminates.  If you're going to use os.popen() on Windows, there's no way around this, so closing as "WontFix" (I agree it's irritating, but there's nothing ZODB can do about it).

You could try to get Microsoft to change Windows -- heh. Python 2.4 has a new "subprocess" module with an optional close_fds true/false argument, but close_fds isn't supported on Windows.

So if you need to do this, you'll have to move to a non-Windows OS; extend Python 2.4's subprocess module (to implement close_fds for Windows); or write a wrapper program that closes inherited file handles before spawning the process you really want to run.
________________________________________
= Assign - Entry #3 by tim_one on Feb 7, 2005 11:20 am

 Status: Pending => Accepted

 Supporters added: tim_one

Assigned myself.
________________________________________
= Edit - Entry #2 by tim_one on Feb 7, 2005 11:19 am

 Changes: importance (critical => medium), new comment

This isn't "critical"; downgrading to "medium".
________________________________________
= Request - Entry #1 by Anonymous User on Feb 7, 2005 9:01 am

If I open a ZODB db/conn/storage, then make a os.popen to completely unrelated dos-command, remember the open popen-file (global; I never enter something of that popen stuff into the ZODB tree), then try to close the ZODB conn/db I get a strange lock permission error. If I close the popen-stream, and then close the ZODB, its works - but that is a buggy condition!? I want the stream to be open. The stream has nothing at all to do with the ZODB stuff.
Its very spezific on os.popen - not with normal file open.

----
        z_conn=...

        cmd=r'C:\bin\gnuplot\pgnuplot.exe'
        g = os.popen(cmd, 'w')
        global glob_file
        glob_file=g
        #glob_file=open('chart.txt')
        #g.write('set data style linespoints'+'\n')
        #g.flush()

         z_conn.close()
         z_db.close()
-----
  File "C:\devel\PythonPlus\zdb.py", line 46, in close
    self.db.close()
  File "C:\PYTHON23\Lib\site-packages\ZODB\DB.py", line 321, in close
    self._storage.close()
  File "C:\PYTHON23\Lib\site-packages\ZODB\FileStorage\FileStorage.py", line 392, in close
    self._lock_file.close()
  File "C:\PYTHON23\Lib\site-packages\ZODB\lock_file.py", line 74, in close
    os.unlink(self._path)
OSError: [Errno 13] Permission denied: 'C:/devel/application/stock.dbx.lock'
>>> 
==============================================================