On Thu, Dec 04, 2014 at 10:04:29AM -0800, Junio C Hamano wrote:
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html