Re: fetching packs and storing them as packs

Linus Torvalds <torvalds@osdl.org> writes:

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.

Noted; will fix.