On 06/19/2013 08:56 PM, Jeff King wrote: > On Wed, Jun 19, 2013 at 09:51:21AM +0200, Michael Haggerty wrote: > >> Re-roll of mh/ref-races. Thanks to Peff, Junio, and Ramsay for >> reviewing v1. > > Thanks. I just read through them again. Everything looks good to me. > > Patches 10 and 11 are missing my signoff, but obviously: > > Signed-off-by: Jeff King <peff@xxxxxxxx> > >> The last patch is still optional--it avoids a little bit of work when >> rewriting the packed-refs file, but relies on the stat-based freshness >> check not giving a false negative. > > I don't have a real problem with it, but given the cygwin confusions > that Ramsay mentioned, maybe it is better to hold back on it for now? It > sounds like the cygwin problems go the other way (false positives > instead of false negatives). I just realized that there is another long-standing problem in loose/packed refs handling: Suppose there is a loose reference for which an old version is still present in the packed-refs file. If the reference is deleted: 1. delete_ref() gets a lock on the loose reference file 2. delete_ref() deletes the loose reference file while retaining the lock 3. delete_ref() calls repack_without_ref() 4. repack_without_ref() tries to acquire a lock on the packed-refs file to delete the packed version of the reference. If the packed-refs file is already locked by another process (and there is no reason why that cannot be, and there is only one attempt to acquire the lock), then repack_without_ref() emits an error and returns with an error code. delete_ref() passes the error along, but doesn't restore the loose ref. The net result is that an old version of the ref (namely the one in the loose refs file) has been revived. That version might even point at an object that has already been garbage collected. This problem is similar to race conditions that have been discussed earlier, but this problem has nothing to do with the freshness/staleness of the packed-refs file WRT to the loose reference; it only depends on the packed-refs file being locked by another process at an inopportune time. I think this problem would also be fixed by the locking scheme that I proposed earlier [1]: to acquire and hold the packed-refs lock across the modification of *both* files, and to rewrite the packed-refs file *before* deleting the loose-refs file (because rewriting the packed-refs file without the to-be-deleted reference is a logical NOP). Michael [1] http://article.gmane.org/gmane.comp.version-control.git/212131 -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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