summaryrefslogtreecommitdiff
path: root/t/t5000
AgeCommit message (Collapse)AuthorFilesLines
2019-07-01t5000: make hash independentLibravatar brian m. carlson1-0/+0
This test uses a stub of a very large (64 GB) object to test our generation of tar archives. In doing so, it uses the object ID of the object so it can insert it into the database properly. Look up these values using test_oid. Restructure the test slightly to use test_oid_in_path. Since we care about the object, not how it is named in a particular hash algorithm, rename it to "huge-object", which is shorter and more descriptive. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-01t5000: test tar files that overflow ustar headersLibravatar Jeff King2-0/+0
The ustar format only has room for 11 (or 12, depending on some implementations) octal digits for the size and mtime of each file. For values larger than this, we have to add pax extended headers to specify the real data, and git does not yet know how to do so. Before fixing that, let's start off with some test infrastructure, as designing portable and efficient tests for this is non-trivial. We want to use the system tar to check our output (because what we really care about is interoperability), but we can't rely on it: 1. being able to read pax headers 2. being able to handle huge sizes or mtimes 3. supporting a "t" format we can parse So as a prerequisite, we can feed the system tar a reference tarball to make sure it can handle these features. The reference tar here was created with: dd if=/dev/zero seek=64G bs=1 count=1 of=huge touch -d @68719476737 huge tar cf - --format=pax | head -c 2048 using GNU tar. Note that this is not a complete tarfile, but it's enough to contain the headers we want to examine. Likewise, we need to convince git that it has a 64GB blob to output. Running "git add" on that 64GB file takes many minutes of CPU, and even compressed, the result is 64MB. So again, I pre-generated that loose object, and then took only the first 2k of it. That should be enough to generate 2MB of data before hitting an inflate error, which is plenty for us to generate the tar header (and then die of SIGPIPE while streaming the rest out). The tests are split so that we test as much as we can even with an uncooperative system tar. This actually catches the current breakage (which is that we die("BUG") trying to write the ustar header) on every system, and then on systems where we can, we go farther and actually verify the result. Helped-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-20t5000: test long filenamesLibravatar René Scharfe1-0/+0
Add a file with a long name to the test archive in order to check entries with pax extended headers. Also add a check for tar versions that doen't understand this format. Those versions should extract the headers as a regular files. Add code to check_tar() to interpret the path header if present, so that our tests work even with those tar versions. It's important to use the fallback code only if needed to still be able to detect git archive errorously creating pax headers as regular file entries (with a suitable tar version, of course). The archive used to check for pax header support in tar was generated using GNU tar 1.26 and its option --format=pax. Tested successfully on NetBSD 6.1, which has a tar version lacking pax header support. Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>