On 24/05/2011 21:18, Claudiu Nicolaie CISMARU wrote:
Now. There is one more issue. Seems that on faster computers and/or
Windows 7 (the Win32 thing I have tested on a HVM Xen machine with
Windows XP) the os.rename is too fast after fp.close() and generates the
same Exception. The code follows:
curl.close()
fp.close()
os.rename(tfile, actualfile)
Where, tfile is the .part file, actual file is the real destination, fp
was opened with open(..., "wb") and the descriptor passed to curl.
I have solved the issue with self.msleep(10) - msleep is a method of
QThread. But I don't think it's an elegant and normal solution. Did
fp.close() is delayed, or? I mean, I don't want to rely on a "sleep" in
order to workaround the access issue.
There used to be a problem with subprocess fds being held by
a traceback. IIRC, the problem could be triggered by having
an except clause around a subprocess call within which something
attempted to, eg,
remove one of the affected files. I'm sorry if that's a bit
of a woolly description but if you think this might be
biting you I'll dive in and look at the code. What version
of Python are you using?
(That said, the fact that the behaviour varies between faster
and slower computers makes that cause unlikely. Maybe we're
back to looking at virus checkers and the like...)
TJG
--
http://mail.python.org/mailman/listinfo/python-list
