Kevin Dangoor wrote: > On 10/21/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > > > Kevin Dangoor wrote: > > > I just remembered that Windows file modification time apparently is > > > only accurate within a couple of seconds. rsync has a parameter to > > > deal with this skew. So, if you're checking modification times to see > > > if you should overwrite a file, you may want to apply a small bit of > > > slush instead of a straight ==. > > > > Wouldn't that fail consistently, then? I mean, each time the file gets > > extracted, the time would be wrong again in that case. > > I had thought that the problem was something to do with how the > modification time was stored, but (from a quick google search) it > actually appears to be related to how the modification time is created > in the first place. Given that, I think you're right... it would be > consistent.
I think I've got this figured out, now, or at least I've figured out one way to cause this. If you install an egg of a given version, let's say TurboGears 0.8a1, and you then *rebuild the egg without changing the version number* and reinstall it (or the distributor rebuilds it and you reinstall it), *and* you're on Windows, *and* you used it at least once before reinstalling, *and* it contains a C extension and was installed zipped... then you will get this error. I went back to look at previous reports of this error to see if they matched all these criteria, and it's hard to tell whether the rebuild+reinstall occurred in each case. Sometimes people said they quote "installed from scratch", but it's not clear whether they really meant installing or reinstallling, and impossible to tell if an egg rebuild was involved. But, this is definitely a way to create the problem, so I'm going to fix it for the official release of 0.6a6 this weekend. The problem is that in this scenario, there's an existing copy of the C extension extracted, but Windows doesn't delete a destination file when you rename a source file to it. The code checks in this case to see if the target file has the same size and timestamp as what it's trying to extract, and if so assumes it's done. If they're different (as they could be after a rebuild), it currently punts, on the theory that something's wrong. On Windows, however, it should try to remove the old file and then attempt to replace it again.
