Package: fake-hwclock Version: 0.10 On bug #763589, protection was added around the save operation so that the saved time cannot go backwards without forcing. While this clearly mitigates the race condition of concern, I don't believe it is an acceptable solution for normal users.
Consider the following use case... 1. The user accidentally sets a wrong time to a date in the future -- for example, sets the year to 2017 rather than 2016 2. The fake-hwclock.data file is written with the future time 3. The user then realizes the mistake, and tries to fix the time back to the year 2016 4. Now, the cron job and service will not update the fake-hwclock.data, since it appears that the current system time is in the past (relative to the invalid saved time) 5. On reboot, the clock reverts to the future date in the year 2017, and continues to do so on every reboot for the next year (unless the user is advanced enough to know to manually run the script with the force flag) Other than races on startup, the normal case is that the system time will not go backwards unless it was intentionally changed (either by a user or by an update from an NTP server), so I don't believe it makes sense to reject such saves by default. (The protection for loads, on the other hand, is clearly needed.) For my specific use case, I simply reverted to the original behavior without any protection against saving, but I suppose the upstream solution would require an alternate solution to the race reported on #763589. -- ............................................................................ *Roddy Shuler* | +1.585.530.7960 | Endless
