Merge lp:~gz/bzr/installer_plugin_script_timestamp_rounding into lp:bzr
| Status: | Merged |
|---|---|
| Approved by: | Robert Collins on 2010-07-04 |
| Approved revision: | 5332 |
| Merged at revision: | 5333 |
| Proposed branch: | lp:~gz/bzr/installer_plugin_script_timestamp_rounding |
| Merge into: | lp:bzr |
| Diff against target: |
18 lines (+8/-0) 1 file modified
setup.py (+8/-0) |
| To merge this branch: | bzr merge lp:~gz/bzr/installer_plugin_script_timestamp_rounding |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Robert Collins (community) | 2010-07-03 | Approve on 2010-07-04 | |
|
Review via email:
|
|||
Commit Message
Make windows installer use a 2 second resolution for plugin script timestamps to avoid recompilation at runtime
Description of the Change
See bug 600803 for the background. The aim is to avoid a potential problem when installing onto a FAT filesystem.
By rounding the timestamps of the plugin script files prior to byte compilation, can ensure that the py mtime and pyo internal timestamp match, even with a 2 second resolution installation drive. Without this change bzr.exe may semi-randomly recompile some pyo files from source at runtime.
Nevertheless, this is a daft hack for a weird edge case, so might not be worth merging.
Ideally all this py2exe stuff would live in bzr-windows-
| John A Meinel (jameinel) wrote : | # |
| Martin Packman (gz) wrote : | # |
It doesn't currently matter as lp:~gz/bzr-windows-installers/use_utc_timestamps_600803 now also prevents Inno from doing any rounding. Just that change covers the far more common case of installing onto NTFS, this is just icing for FAT. It may be possible to let Inno continue to round, but apart from then being able to notice problems with this code even on NTFS I see absolutely no benefit in having the installer mess with timestamps.
- 5333. By Martin Packman on 2010-07-04
-
Use same timestamp rounding logic as Inno, just in case
| Martin Packman (gz) wrote : | # |
For the curious, the Inno logic in Compile.pas goes like:
Dec64(
Where FL.TimeStamp is FILETIME derived 100-nanosecond counter, and 'Dec' stands for decrement.
I've updated this branch to do the same, so it would be safe not to use TimeStampRounding=0 and leave the default of 2.
| Martin Packman (gz) wrote : | # |
sent to pqm by email

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin [gz] wrote: installers where sane people don't have to look at it, but some poor fool has to volunteer to do that still I guess.
> Martin [gz] has proposed merging lp:~gz/bzr/installer_plugin_script_timestamp_rounding into lp:bzr.
>
> Requested reviews:
> bzr-core (bzr-core)
>
>
> See bug 600803 for the background. The aim is to avoid a potential problem when installing onto a FAT filesystem.
>
> By rounding the timestamps of the plugin script files prior to byte compilation, can ensure that the py mtime and pyo internal timestamp match, even with a 2 second resolution installation drive. Without this change bzr.exe may semi-randomly recompile some pyo files from source at runtime.
>
> Nevertheless, this is a daft hack for a weird edge case, so might not be worth merging.
>
> Ideally all this py2exe stuff would live in bzr-windows-
>
Are we sure we round the same way ISS does? Would it be better to just
disable the rounding check?
John
=:->
-----BEGIN PGP SIGNATURE----- enigmail. mozdev. org/
vuooACgkQJdeBCY SNAAP/LwCgsoM12 Qhe125JgxI/ nF27fsiL 1Y7GggYp8hdSi99 3O
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkw
2JwAn3u5EoGDpcw
=+LI5
-----END PGP SIGNATURE-----