mirrors/git
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

index: be careful when handling long names

Browse Source 
We currently use lower 12-bit (masked with CE_NAMEMASK) in the
ce_flags field to store the length of the name in cache_entry,
without checking the length parameter given to
create_ce_flags().  This can make us store incorrect length.

Currently we are mostly protected by the fact that many
codepaths first copy the path in a variable of size PATH_MAX,
which typically is 4096 that happens to match the limit, but
that feels like a bug waiting to happen.  Besides, that would
not allow us to shorten the width of CE_NAMEMASK to use the bits
for new flags.

This redefines the meaning of the name length stored in the
cache_entry.  A name that does not fit is represented by storing
CE_NAMEMASK in the field, and the actual length needs to be
computed by actually counting the bytes in the name[] field.
This way, only the unusually long paths need to suffer.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Junio C Hamano
2008-01-18 23:42:00 -08:00
committed by Linus Torvalds
parent 7a51ed66f6
commit 7fec10b7f4
3 changed files with 46 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
t/t0000-basic.sh
View File

@ -297,4 +297,24 @@ test_expect_success 'absolute path works as expected' '
test "$sym" = "$(test-absolute-path $dir2/syml)"
'
test_expect_success 'very long name in the index handled sanely' '
a=a && # 1
a=$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a && # 16
a=$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a && # 256
a=$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a$a && # 4096
a=${a}q &&
>path4 &&
git update-index --add path4 &&
(
git ls-files -s path4 |
sed -e "s/ .*/ /" |
tr -d "\012"
echo "$a"
) | git update-index --index-info &&
len=$(git ls-files "a*" | wc -c) &&
test $len = 4098
'
test_done