Re: [PATCH 0/2] Support for packs in HTTP

From: Linus Torvalds <torvalds@osdl.org>
Date: Jul 11, 2005, 17:44 UTC
Message-ID: <Pine.LNX.4.58.0507111040251.17536@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.21.0507102337160.30848-100000@iabervon.org>

On Mon, 11 Jul 2005, Daniel Barkalow wrote:

Show 13 quoted lines

> On Sun, 10 Jul 2005, Linus Torvalds wrote:
> 
> > 
> > You really _mustn't_ try to create the pack directly to the
> > $GIT_DIR/objects/pack subdirectory - that would make git itself start
> > possibly using that pack before the index is all done, and that would be
> > just wrong and nasty.
> >
> > So you really should _always_ generate the pack somewhere else, and then 
> > move it (pack file first, index file second).
> 
> It's currently fine ignoring index files without corresponding
> pack files (sha1_file.c, line 470).

That doesn't help.

Redgardless of which order you write them (and you _will_ write the pack-file first), you'll find that at some point you have both files, but one or the other isn't fully written, ie they are unusable.

And yes, you can handle that by always checking the SHA1 of the files when you open them, but the fact is, you shouldn't need to, just to use it. Checking the SHA1 of the pack-file in particular is very expensive (since it's potentially a huge file, and you don't even want to read all of it).

So you could have rules like: pack-file must get populated first, and index file must be SHA1-checked by all users.

Or, you could just have a saner rule: create the pack-files somewhere else, and move them atomically to the right place. Problem solved.

So that's what I decided the rule is: never ever have a partial file, and thus you can by definition use them immediately when you see both files.

But that requires that you write them under another name than the final one. And since you want that _anyway_ for other uses, you don't hide that inside "git-pack-objects", but you make it an exported interface.

		Linus