Linus Torvalds <torvalds@osdl.org> writes:

quoted text
> We really should _never_ create a pack in-place with the final name.

The "fattening" index-pack Nico did does not have this problem
as far as I can see.  Under --stdin, it creates a temporary pack
file "$GIT_OBJECT_DIRECTORY/pack_XXXXXX"; after the received
pack is fattened by adding missing delta-base objects and fixing
up the pack header, final() moves the {pack,idx} pair to the
final location.

The race is about this sequence:

	- git-receive-pack is spawned from remove git-send-pack;
          it lets "index-pack --stdin --fatten" to keep the pack.

	- index-pack does its magic and moves the pack and idx
          to their final location;

	- "repack -a -d" is started by somebody else; it first
          remembers all the existing packs; it does the usual
          repacking-into-one.

	- git-receive-pack that invoked the index-pack waits for
          index-pack to finish, and then updates the refs;

	- "repack -a -d" is done repacking; removes the packs
          that existed when it checked earlier.

Two instances of receive-pack running simultaneously is safe (in
the sense that it does not corrupt the repository; one instance
can fail after noticing the other updated the ref it wanted to
update) and there is no reason to exclude each other.  But
"repack -a -d" and receive-pack are not.

Can we perhaps have reader-writer lock on the filesystem to
pretect the repository?  "prune" can also be made into a writer
for that lock and "fetch-pack --keep" would be a reader for the
lock.  That reader-writer lock would solve the issue rather
nicely.

quoted text
> That said, I think some of the "git repack -d" logic is also unnecessarily 
> fragile.

Noted; will fix.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html