> 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. -- Claudiu Nicolaie CISMARU GNU GPG Key: http://claudiu.targujiu.net/key.gpg T: +40 755 135455 E: clau...@virtuamagic.com, claudiu.cism...@gmail.com
signature.asc
Description: This is a digitally signed message part.
-- http://mail.python.org/mailman/listinfo/python-list
