Re: [PATCH] gc: support temporarily preserving garbage

From: Jeff King <peff@peff.net>
Date: Dec 5, 2014, 09:30 UTC
Message-ID: <20141205093029.GD32112@peff.net>
In-Reply-To: <xmqq388vuw9e.fsf@gitster.dls.corp.google.com>

On Thu, Dec 04, 2014 at 10:04:29AM -0800, Junio C Hamano wrote:

Show 17 quoted lines

> > If it is a problem (and again, I am just guessing), I'd imagine you
> > would need a similar setup to what you proposed for unlink(): before
> > renaming "packed-refs.lock" into "packed-refs", hard-link it into your
> > "trash" area. And you'd probably want to intercept rename() there, to
> > catch all places where we use this technique.
> 
> Also we need to take it into account that it is not an issue unique
> to Git that the server side may expire these .nfsXXXXX entries left
> by an NFS client ("silly rename") to keep files that have been
> removed or renamed away alive.  Aren't there a knob on the NFS
> server end to control how long these are kept unexpired to avoid
> stale filehandle errors, so that not just Git but all applications
> running on NFS client machines will not be hurt by it?
> 
> Working it around at the application program level for each and
> every application that runs on a machine that can NFS mount
> filesystems from elsewhere may be simply madness, no?

Thanks. That is the vague feeling I have about the series, but without having actually _seen_ the problem or knowing to what extent it affects git, I didn't want to say anything so definite (e.g., I am only guessing that rename() is a problem, but from the original description, it sounds quite plausible that it is).

If this can be fixed outside of git, I very much agree that is the best path forward.

-Peff