Julian Melville wrote: > If I delete the contents of Application Data\Python-Eggs (a folder named > celementtree-1.0.2_20050302-py2.4-win32.egg-tmp) then the problem goes > away, but I'm a little concerned whether a similar problem could exist > on Linux, where this will eventually be deployed.
On Unix platforms, this specific error shouldn't happen because renaming a file deletes and overwrites an existing file, even if it's open. So have no worries on that account. On Windows, an open file can't be deleted or renamed, so if you have a Python executable running that has ever imported the celementtree library, no other process can overwrite the file until that other process exits. Now, pkg_resources *shouldn't* be trying to overwrite the file, since it checks the file size and timestamp against those in the zipfile, and should only try to overwrite it if it *differs*. So, I'm confused as to what could be happening here. (It's supposed to leave the directory in place, so that on subsequent usage it doesn't need to unpack the file again if it still has the right timestamp and size.) If you want to make sure this doesn't happen again, you can use the --always-unzip flag to easy_install and reinstall celementtree, and it will be installed as a directory instead of a zipfile. But it would be really good if you could find a way to reproduce the problem instead, so I can find out if it's something fixable. By the way, on all platforms, pkg_resources recognizes the PYTHON_EGG_CACHE environment variable to control the extract location, so if it turns out this is a permissions problem (e.g. no permission to set the timestamp on the extracted file?), you might want to change the PYTHON_EGG_CACHE setting. My code does make the assumption that renaming a file doesn't change its st_mtime, and that if you pass a given value to os.utime() you'll get it back in st_mtime. If there are situtations on Windows where these things don't hold true, then I can see why it would get the error, but then it seems like it should start getting the error on the second run after deleting the file, and it would be routinely reproducible. So, I'm not sure what's happening here.
