# [PATCH 1/2] t5710-info-alternate: demonstrate bug in unpacked pruning 5 messages from 2015-02-01 to 2015-02-02. Participants: Jonathon Mah, Jeff King. Thread: https://gitlist.dev/t/38479 ## Jonathon Mah, 2015-02-01 21:55 Subject: [PATCH 1/2] t5710-info-alternate: demonstrate bug in unpacked pruning Message-ID: URL: https://gitlist.dev/e/BF4AA771-DEB5-4DED-9C74-768036C1E2DD%40jonathonmah.com ``` Signed-off-by: Jonathon Mah --- t/t5710-info-alternate.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh index 5a6e49d..d82844a 100755 --- a/t/t5710-info-alternate.sh +++ b/t/t5710-info-alternate.sh @@ -18,6 +18,7 @@ reachable_via() { test_valid_repo() { git fsck --full > fsck.log && + git prune && test_line_count = 0 fsck.log } @@ -47,8 +48,7 @@ test_expect_success 'preparing third repository' \ 'git clone -l -s B C && cd C && echo "Goodbye, cruel world" > file3 && git add file3 && -git commit -m "one more" file3 && -git repack -a -d -l && +git commit -m "one more without packing" file3 && git prune' cd "$base_dir" -- 2.3.0.rc2.2.g184f7a0 ``` ## Jonathon Mah, 2015-02-01 21:55 Subject: [PATCH 2/2] sha1_file: fix iterating loose alternate objects Message-ID: <50251CB8-0885-40FF-A7C9-9C9460266E14@jonathonmah.com> URL: https://gitlist.dev/e/50251CB8-0885-40FF-A7C9-9C9460266E14%40jonathonmah.com In-Reply-To: ``` The string in 'base' contains a path suffix to a specific object; when its value is used, the suffix must either be filled (as in stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared (as in prepare_packed_git) to avoid junk at the end. loose_from_alt_odb (introduced in 660c889e46d185dc98ba78963528826728b0a55d) did neither and treated 'base' as a complete path to the "base" object directory, instead of a pointer to the "base" of the full path string. The trailing path after 'base' is still initialized to NUL, hiding the bug in some common cases. Additionally the descendent for_each_file_in_obj_subdir function swallows ENOENT, so an error only shows if the alternate's path was last filled with a valid object (where statting /path/to/existing/00/0bjectfile/00 fails). Signed-off-by: Jonathon Mah --- sha1_file.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index 30995e6..fcb1c4b 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -3396,9 +3396,13 @@ static int loose_from_alt_odb(struct alternate_object_database *alt, void *vdata) { struct loose_alt_odb_data *data = vdata; - return for_each_loose_file_in_objdir(alt->base, - data->cb, NULL, NULL, - data->data); + int r; + alt->name[-1] = 0; + r = for_each_loose_file_in_objdir(alt->base, + data->cb, NULL, NULL, + data->data); + alt->name[-1] = '/'; + return r; } int for_each_loose_object(each_loose_object_fn cb, void *data) -- 2.3.0.rc2.2.g184f7a0 ``` ## Jeff King, 2015-02-02 17:53 Subject: Re: [PATCH 2/2] sha1_file: fix iterating loose alternate objects Message-ID: <20150202175259.GA24025@peff.net> URL: https://gitlist.dev/e/20150202175259.GA24025%40peff.net In-Reply-To: <50251CB8-0885-40FF-A7C9-9C9460266E14@jonathonmah.com> ``` On Sun, Feb 01, 2015 at 01:55:33PM -0800, Jonathon Mah wrote: > The string in 'base' contains a path suffix to a specific object; when > its value is used, the suffix must either be filled (as in > stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared > (as in prepare_packed_git) to avoid junk at the end. loose_from_alt_odb > (introduced in 660c889e46d185dc98ba78963528826728b0a55d) did neither and > treated 'base' as a complete path to the "base" object directory, > instead of a pointer to the "base" of the full path string. > > The trailing path after 'base' is still initialized to NUL, hiding the > bug in some common cases. Additionally the descendent > for_each_file_in_obj_subdir function swallows ENOENT, so an error only > shows if the alternate's path was last filled with a valid object > (where statting /path/to/existing/00/0bjectfile/00 fails). Thanks for catching this, and for a nice explanation. > diff --git a/sha1_file.c b/sha1_file.c > index 30995e6..fcb1c4b 100644 > --- a/sha1_file.c > +++ b/sha1_file.c > @@ -3396,9 +3396,13 @@ static int loose_from_alt_odb(struct alternate_object_database *alt, > void *vdata) > { > struct loose_alt_odb_data *data = vdata; > - return for_each_loose_file_in_objdir(alt->base, > - data->cb, NULL, NULL, > - data->data); > + int r; > + alt->name[-1] = 0; > + r = for_each_loose_file_in_objdir(alt->base, > + data->cb, NULL, NULL, > + data->data); > + alt->name[-1] = '/'; > + return r; > } I think this is probably the best fix, and is the pattern we use elsewhere when touching alt->base. We _could_ further change this to have for_each_loose_file_in_objdir actually use alt->base as its scratch buffer, writing the object filenames into the end of it (i.e., what it was designed for). But: 1. We still need a strbuf scratch-buffer for the non-alternate object directory. So we'd have to push more code there to over-allocate the buffer, and then for_each_loose_file_in_objdir would assume we always feed it a buffer with the extra slop. That would work, but I find the strbuf approach a little safer; there's not an implicit over-allocation far away in the code preventing us from overflowing a buffer. 2. The reason for the existing alt->base behavior is that the sha1_file code gets fed objects one at a time, and don't want to pay strbuf overhead for each. With the iterator, we know we are going to hit a bunch of objects, so we only have to pay the strbuf overhead once for the iteration. So there's not the same performance penalty, and we can stick with the strbuf if we prefer it. -Peff ``` ## Jeff King, 2015-02-02 17:56 Subject: Re: [PATCH 1/2] t5710-info-alternate: demonstrate bug in unpacked pruning Message-ID: <20150202175622.GB24025@peff.net> URL: https://gitlist.dev/e/20150202175622.GB24025%40peff.net In-Reply-To: ``` On Sun, Feb 01, 2015 at 01:55:00PM -0800, Jonathon Mah wrote: > Signed-off-by: Jonathon Mah > --- > t/t5710-info-alternate.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh > index 5a6e49d..d82844a 100755 > --- a/t/t5710-info-alternate.sh > +++ b/t/t5710-info-alternate.sh > @@ -18,6 +18,7 @@ reachable_via() { > > test_valid_repo() { > git fsck --full > fsck.log && > + git prune && > test_line_count = 0 fsck.log > } > > @@ -47,8 +48,7 @@ test_expect_success 'preparing third repository' \ > 'git clone -l -s B C && cd C && > echo "Goodbye, cruel world" > file3 && > git add file3 && > -git commit -m "one more" file3 && > -git repack -a -d -l && > +git commit -m "one more without packing" file3 && > git prune' Modifying a test like this makes me a little nervous because now the old test is not checking the same thing (pruning when we are packed), and it's not obvious whether the packing was important to the original test. And it's not clear that this change is testing a totally unrelated thing. I haven't looked closely, but would it be hard to introduce a new test that more explicitly checks for the breakage? -Peff ``` ## Jonathon Mah, 2015-02-02 18:37 Subject: Re: [PATCH 2/2] sha1_file: fix iterating loose alternate objects Message-ID: <9215E7CF-4A6C-48ED-8A63-76085D5B151A@jonathonmah.com> URL: https://gitlist.dev/e/9215E7CF-4A6C-48ED-8A63-76085D5B151A%40jonathonmah.com In-Reply-To: <20150202175259.GA24025@peff.net> ``` > On 2015-02-02, at 09:53, Jeff King wrote: > > I think this is probably the best fix, and is the pattern we use > elsewhere when touching alt->base. > > We _could_ further change this to have for_each_loose_file_in_objdir > actually use alt->base as its scratch buffer, writing the object > filenames into the end of it (i.e., what it was designed for). But: > > 1. We still need a strbuf scratch-buffer for the non-alternate object > directory. So we'd have to push more code there to over-allocate > the buffer, and then for_each_loose_file_in_objdir would assume > we always feed it a buffer with the extra slop. That would work, > but I find the strbuf approach a little safer; there's not an > implicit over-allocation far away in the code preventing us from > overflowing a buffer. > > 2. The reason for the existing alt->base behavior is that the > sha1_file code gets fed objects one at a time, and don't want to > pay strbuf overhead for each. With the iterator, we know we are > going to hit a bunch of objects, so we only have to pay the strbuf > overhead once for the iteration. So there's not the same > performance penalty, and we can stick with the strbuf if we prefer > it. Thanks for your feedback. I considered the same, and came to a similar conclusion. The strbuf cost is only once per alternate, so I feel on balance it's more robust to use alt->base consistently inside each function, rather than have this a more fragile special case to save allocation of only one path. Updated the test patch. Jonathon Mah me@JonathonMah.com ```