Linus Torvalds <torvalds@xxxxxxxx> writes:
> 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.
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html