Am 16.04.20 um 07:09 schrieb Jeff King: > We do add a ".keep" between writing the pack and updating the refs, but > it doesn't look like it's done atomically (i.e., we write the .idx file > and _then_ add the .keep). So there's a small race there. > > But all of this is also true of any operation, like git-commit. It's > creating new loose objects, and then will try to reference them. In > between, a simultaneous gc will think they're unreachable. Likewise, > receiving a push may write a pack (with a .keep, though in the correct > order) or even loose objects. > > This is usually handled by the gc expiration time, which is compared > against the file mtime. The default is 2 weeks, but even something short > like 5 minutes would be plenty to avoid this race (even for a long > import, we should be updating the mtime every time we call write()). Except that on Windows the times are only updated reliably when all file handles refering to the file are closed. Would that poke a hole in your argument? (I don't think so, as long as expiration times are not ridiculously short; and people who do gc --prune=now should know what they are doing -- and when.) > In fact, gc will use the same expiration for clearing out tempfiles. So > even before we write the final pack and its .keep, any temporary files > we're writing into would be at risk. But again, if we're actively > writing, their mtimes should save them. -- Hannes
