Re: "prune" prone to clock skew (Re: t3306 failure with v1.7.5-rc1)

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2011, 18:51 UTC
Message-ID: <7vei5c4lwh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110408163021.GB32709@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> So I don't know that it's worth fixing, nor do I know what your "proper
> checks" would be. We could open up commits we're about to prune and
> check their timestamps for age. That wouldn't help blobs and trees. For
> them, we could make a guess as to their age by seeing if they're
> connected to any dangling commits, and using the commit timestamp. But
> that will only cover some objects, and it is also still vulnerable to
> certain types of clock skew (though it is more robust, since you would
> need a client and server with one type writing the objects, and then
> another skewed client doing the prune, which is even less likely).

I don't personally think this is worth addressing, but as I was Cc'ed, I'll try.

If we at least know that the object store is contained within a single filesystem whose clock is at least guaranteed to monotonically increase, one possible workaround would be to touch a garbage file and read its timestamp, instead of grabbing the current time from the local clock, no?