On Fri, Apr 08, 2016 at 09:10:08PM +0100, Robie Basak wrote:
>On Fri, Apr 08, 2016 at 06:49:35PM +0100, Steve McIntyre wrote:
>> The problem is that I don't think there's a good solution to both
>> problems here. We can't *know* that the system time has been read from
>> fake-hwclock.data before
On Fri, Apr 08, 2016 at 06:49:35PM +0100, Steve McIntyre wrote:
> The problem is that I don't think there's a good solution to both
> problems here. We can't *know* that the system time has been read from
> fake-hwclock.data before calling "save". I briefly considered adding a
> "I've seen this"
> What we *can* do is instead add an extra declaration of system time
> based on the build/release date of the particular version of the
> fake-hwclock package in use, and refuse to back to a date before
> *that* unless --force is used. How does that sound?
That sounds like a good policy in
[ Including a CC to Robie from the previous bug #763589... ]
Hey guys,
On Tue, Mar 22, 2016 at 11:37:56PM +, Roddy Shuler wrote:
>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
Following up, another important use case (which turned out to be what
caused problems for us in the first case)... At least with some hardware
implementations, upon disconnecting and reconnecting the battery, the
hardware clock is initialized to a random date/time, which can easily be
years in
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
6 matches
Mail list logo
