Re: Diagnosing stray/stale .keep files -- explore what is in a pack?

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Jan 15, 2014, 23:50 UTC
Message-ID: <CACPiFC+koU1Fan+tbE2YgOstWGsDtDihpK-7CMOct7XAEpwJ2A@mail.gmail.com>
In-Reply-To: <xmqqr4892l0u.fsf@gitster.dls.corp.google.com>

On Wed, Jan 15, 2014 at 12:49 PM, Junio C Hamano <gitster@pobox.com> wrote:

> As long as we can reliably determine that it is safe to do so
> without risking races, automatically cleaning .lock files is a good
> thing to do.

If the .lock file is a day old, it seems to me that it should be safe to call it stale.

Can anyone "take the lock" if there is already a lock file?

Show 6 quoted lines

> Cleaning .keep files needs the same care and a bit more, though.
> You of course have to be sure that no other concurrent process is in
> the middle of doing something, but you also need to be sure that the
> ".keep" file is not a marker created by the end user to say "keep
> this pack, do not subject its contents to repacking" after a careful
> repacking of the stable part of the history.

For the keep files, I already drafted a script that looks inside the keep file, if it reads 'receive-pack [pid] [host]' it checks whether the hostname matches, and if so whether the pid matches a running process.

Only if the host matches and the pid is dead we call it stale.

Seems fairly conservative to me. Are there scenarios where we think this can misfire?

-- 
 martin.langhoff@gmail.com
 -  ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 ~ http://docs.moodle.org/en/User:Martin_Langhoff