On 5/24/2011 4:18 PM, Claudiu Nicolaie CISMARU wrote:
Seems that close_fds did the trick. Anyway, I read that description on
the documentation last night but I think I was so tired that I
understood that in Windows has no effect... :)

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.

On this issue there is no more process spawn, nothing, just the
downloader thread and the main window. And the access denied appears at
random time.

I would go with what works. In my experience, mysterious and seemingly buggy error messages, including Access Denied are not unusual on Windows.

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to