Perfect! Thanks for your suggestion, Steve. That does sound like a cleaner solution than what I had proposed.
Roddy On Mon, Feb 29, 2016 at 5:28 PM Steve McIntyre <st...@einval.com> wrote: > Hi Roddy, and thanks for getting in touch! > > On Wed, Feb 24, 2016 at 09:27:26PM +0000, Roddy Shuler wrote: > >Package: fake-hwclock > >Version: 0.9 > > > >Upon first use of fake-hwclock, if the device does not have a > >battery-backed clock (and has not saved fake-hwclock.data yet), the clock > >will typically start at Jan 1, 1970 UTC. This has the following > >repercussions: > >- Before manually adjusting the time, it will be behind other files on the > >system > >- Manual adjustment of the clock via a UI with a mouse will require > several > >clicks to increment the year from 1970 to the current > >- If the user does not adjust the time, website certificates will be > >rejected as not yet valid > > > >While a fake clock is never perfect, we can get closer to reality by > keying > >off of the modification time of a file or directory, so that on first boot > >the clock will effectively be set to a time that is no earlier than the > >time at which the file system was built. Using the root directory (/) > >seems safest as it is a directory that can be assumed to always exist. > > OK, I see your logic but I'm not sure it's the way I'd choose to > go. What you *have* identified is that there's a hole in the package > such that it may not get to save a state file before rebooting. I'm > thinking a better fix would be to add a call to "fake-hwclock save" in > the postinst. How does that sound? > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > "Further comment on how I feel about IBM will appear once I've worked out > whether they're being malicious or incompetent. Capital letters are > forecast." > Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html > > -- ............................................................................ *Roddy Shuler* | +1.585.530.7960 | Endless
