2006-09-24 15:31:10 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2005, 2006 Rene Scharfe
|
|
|
|
|
*/
|
|
|
|
|
#include "cache.h"
|
|
|
|
|
#include "tar.h"
|
|
|
|
|
#include "archive.h"
|
2012-05-03 01:51:04 +00:00
|
|
|
#include "streaming.h"
|
2011-06-22 01:26:31 +00:00
|
|
|
#include "run-command.h"
|
2006-09-24 15:31:10 +00:00
|
|
|
|
|
|
|
|
#define RECORDSIZE (512)
|
|
|
|
|
#define BLOCKSIZE (RECORDSIZE * 20)
|
|
|
|
|
|
|
|
|
|
static char block[BLOCKSIZE];
|
|
|
|
|
static unsigned long offset;
|
|
|
|
|
|
2007-01-05 22:30:22 +00:00
|
|
|
static int tar_umask = 002;
|
2006-09-24 15:31:10 +00:00
|
|
|
|
2011-06-22 01:26:31 +00:00
|
|
|
static int write_tar_filter_archive(const struct archiver *ar,
|
|
|
|
|
struct archiver_args *args);
|
|
|
|
|
|
archive-tar: write extended headers for file sizes >= 8GB
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
077777777777, or 1 byte short of 8GB. The correct solution
for a larger file, according to POSIX.1-2001, is to add an
extended pax header, similar to how we handle long
filenames. This patch does that, and writes zero for the
size field in the ustar header (the last bit is not
mentioned by POSIX, but it matches how GNU tar behaves with
--format=pax).
This should be a strict improvement over the current
behavior, which is to die in xsnprintf with a "BUG".
However, there's some interesting history here.
Prior to f2f0267 (archive-tar: use xsnprintf for trivial
formatting, 2015-09-24), we silently overflowed the "size"
field. The extra bytes ended up in the "mtime" field of the
header, which was then immediately written itself,
overwriting our extra bytes. What that means depends on how
many bytes we wrote.
If the size was 64GB or greater, then we actually overflowed
digits into the mtime field, meaning our value was
effectively right-shifted by those lost octal digits. And
this patch is again a strict improvement over that.
But if the size was between 8GB and 64GB, then our 12-byte
field held all of the actual digits, and only our NUL
terminator overflowed. According to POSIX, there should be a
NUL or space at the end of the field. However, GNU tar seems
to be lenient here, and will correctly parse a size up 64GB
(minus one) from the field. So sizes in this range might
have just worked, depending on the implementation reading
the tarfile.
This patch is mostly still an improvement there, as the 8GB
limit is specifically mentioned in POSIX as the correct
limit. But it's possible that it could be a regression
(versus the pre-f2f0267 state) if all of the following are
true:
1. You have a file between 8GB and 64GB.
2. Your tar implementation _doesn't_ know about pax
extended headers.
3. Your tar implementation _does_ parse 12-byte sizes from
the ustar header without a delimiter.
It's probably not worth worrying about such an obscure set
of conditions, but I'm documenting it here just in case.
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:16 +00:00
|
|
|
/*
|
|
|
|
|
* This is the max value that a ustar size header can specify, as it is fixed
|
|
|
|
|
* at 11 octal digits. POSIX specifies that we switch to extended headers at
|
|
|
|
|
* this size.
|
archive-tar: write extended headers for far-future mtime
The ustar format represents timestamps as seconds since the
epoch, but only has room to store 11 octal digits. To
express anything larger, we need to use an extended header.
This is exactly the same case we fixed for the size field in
the previous commit, and the solution here follows the same
pattern.
This is even mentioned as an issue in f2f0267 (archive-tar:
use xsnprintf for trivial formatting, 2015-09-24), but since
it only affected things far in the future, it wasn't deemed
worth dealing with. But note that my calculations claiming
thousands of years were off there; because our xsnprintf
produces a NUL byte, we only have until the year 2242 to fix
this.
Given that this is just around the corner (geologically
speaking, anyway), and because it's easy to fix, let's just
make it work. Unlike the previous fix for "size", where we
had to write an individual extended header for each file, we
can write one global header (since we have only one mtime
for the whole archive).
There's a slight bit of trickiness there. We may already be
writing a global header with a "comment" field for the
commit sha1. So we need to write our new field into the same
header. To do this, we push the decision of whether to write
such a header down into write_global_extended_header(),
which will now assemble the header as it sees fit, and will
return early if we have nothing to write (in practice, we'll
only have a large mtime if it comes from a commit, but this
makes it also work if you set your system clock ahead such
that time() returns a huge value).
Note that we don't (and never did) handle negative
timestamps (i.e., before 1970). This would probably not be
too hard to support in the same way, but since git does not
support negative timestamps at all, I didn't bother here.
After writing the extended header, we munge the timestamp in
the ustar headers to the maximum-allowable size. This is
wrong, but it's the least-wrong thing we can provide to a
tar implementation that doesn't understand pax headers (it's
also what GNU tar does).
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:20 +00:00
|
|
|
*
|
|
|
|
|
* Likewise for the mtime (which happens to use a buffer of the same size).
|
archive-tar: write extended headers for file sizes >= 8GB
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
077777777777, or 1 byte short of 8GB. The correct solution
for a larger file, according to POSIX.1-2001, is to add an
extended pax header, similar to how we handle long
filenames. This patch does that, and writes zero for the
size field in the ustar header (the last bit is not
mentioned by POSIX, but it matches how GNU tar behaves with
--format=pax).
This should be a strict improvement over the current
behavior, which is to die in xsnprintf with a "BUG".
However, there's some interesting history here.
Prior to f2f0267 (archive-tar: use xsnprintf for trivial
formatting, 2015-09-24), we silently overflowed the "size"
field. The extra bytes ended up in the "mtime" field of the
header, which was then immediately written itself,
overwriting our extra bytes. What that means depends on how
many bytes we wrote.
If the size was 64GB or greater, then we actually overflowed
digits into the mtime field, meaning our value was
effectively right-shifted by those lost octal digits. And
this patch is again a strict improvement over that.
But if the size was between 8GB and 64GB, then our 12-byte
field held all of the actual digits, and only our NUL
terminator overflowed. According to POSIX, there should be a
NUL or space at the end of the field. However, GNU tar seems
to be lenient here, and will correctly parse a size up 64GB
(minus one) from the field. So sizes in this range might
have just worked, depending on the implementation reading
the tarfile.
This patch is mostly still an improvement there, as the 8GB
limit is specifically mentioned in POSIX as the correct
limit. But it's possible that it could be a regression
(versus the pre-f2f0267 state) if all of the following are
true:
1. You have a file between 8GB and 64GB.
2. Your tar implementation _doesn't_ know about pax
extended headers.
3. Your tar implementation _does_ parse 12-byte sizes from
the ustar header without a delimiter.
It's probably not worth worrying about such an obscure set
of conditions, but I'm documenting it here just in case.
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:16 +00:00
|
|
|
*/
|
2016-07-14 20:04:43 +00:00
|
|
|
#if ULONG_MAX == 0xFFFFFFFF
|
|
|
|
|
#define USTAR_MAX_SIZE ULONG_MAX
|
|
|
|
|
#define USTAR_MAX_MTIME ULONG_MAX
|
|
|
|
|
#else
|
archive-tar: write extended headers for file sizes >= 8GB
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
077777777777, or 1 byte short of 8GB. The correct solution
for a larger file, according to POSIX.1-2001, is to add an
extended pax header, similar to how we handle long
filenames. This patch does that, and writes zero for the
size field in the ustar header (the last bit is not
mentioned by POSIX, but it matches how GNU tar behaves with
--format=pax).
This should be a strict improvement over the current
behavior, which is to die in xsnprintf with a "BUG".
However, there's some interesting history here.
Prior to f2f0267 (archive-tar: use xsnprintf for trivial
formatting, 2015-09-24), we silently overflowed the "size"
field. The extra bytes ended up in the "mtime" field of the
header, which was then immediately written itself,
overwriting our extra bytes. What that means depends on how
many bytes we wrote.
If the size was 64GB or greater, then we actually overflowed
digits into the mtime field, meaning our value was
effectively right-shifted by those lost octal digits. And
this patch is again a strict improvement over that.
But if the size was between 8GB and 64GB, then our 12-byte
field held all of the actual digits, and only our NUL
terminator overflowed. According to POSIX, there should be a
NUL or space at the end of the field. However, GNU tar seems
to be lenient here, and will correctly parse a size up 64GB
(minus one) from the field. So sizes in this range might
have just worked, depending on the implementation reading
the tarfile.
This patch is mostly still an improvement there, as the 8GB
limit is specifically mentioned in POSIX as the correct
limit. But it's possible that it could be a regression
(versus the pre-f2f0267 state) if all of the following are
true:
1. You have a file between 8GB and 64GB.
2. Your tar implementation _doesn't_ know about pax
extended headers.
3. Your tar implementation _does_ parse 12-byte sizes from
the ustar header without a delimiter.
It's probably not worth worrying about such an obscure set
of conditions, but I'm documenting it here just in case.
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:16 +00:00
|
|
|
#define USTAR_MAX_SIZE 077777777777UL
|
archive-tar: write extended headers for far-future mtime
The ustar format represents timestamps as seconds since the
epoch, but only has room to store 11 octal digits. To
express anything larger, we need to use an extended header.
This is exactly the same case we fixed for the size field in
the previous commit, and the solution here follows the same
pattern.
This is even mentioned as an issue in f2f0267 (archive-tar:
use xsnprintf for trivial formatting, 2015-09-24), but since
it only affected things far in the future, it wasn't deemed
worth dealing with. But note that my calculations claiming
thousands of years were off there; because our xsnprintf
produces a NUL byte, we only have until the year 2242 to fix
this.
Given that this is just around the corner (geologically
speaking, anyway), and because it's easy to fix, let's just
make it work. Unlike the previous fix for "size", where we
had to write an individual extended header for each file, we
can write one global header (since we have only one mtime
for the whole archive).
There's a slight bit of trickiness there. We may already be
writing a global header with a "comment" field for the
commit sha1. So we need to write our new field into the same
header. To do this, we push the decision of whether to write
such a header down into write_global_extended_header(),
which will now assemble the header as it sees fit, and will
return early if we have nothing to write (in practice, we'll
only have a large mtime if it comes from a commit, but this
makes it also work if you set your system clock ahead such
that time() returns a huge value).
Note that we don't (and never did) handle negative
timestamps (i.e., before 1970). This would probably not be
too hard to support in the same way, but since git does not
support negative timestamps at all, I didn't bother here.
After writing the extended header, we munge the timestamp in
the ustar headers to the maximum-allowable size. This is
wrong, but it's the least-wrong thing we can provide to a
tar implementation that doesn't understand pax headers (it's
also what GNU tar does).
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:20 +00:00
|
|
|
#define USTAR_MAX_MTIME 077777777777UL
|
2016-07-14 20:04:43 +00:00
|
|
|
#endif
|
archive-tar: write extended headers for file sizes >= 8GB
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
077777777777, or 1 byte short of 8GB. The correct solution
for a larger file, according to POSIX.1-2001, is to add an
extended pax header, similar to how we handle long
filenames. This patch does that, and writes zero for the
size field in the ustar header (the last bit is not
mentioned by POSIX, but it matches how GNU tar behaves with
--format=pax).
This should be a strict improvement over the current
behavior, which is to die in xsnprintf with a "BUG".
However, there's some interesting history here.
Prior to f2f0267 (archive-tar: use xsnprintf for trivial
formatting, 2015-09-24), we silently overflowed the "size"
field. The extra bytes ended up in the "mtime" field of the
header, which was then immediately written itself,
overwriting our extra bytes. What that means depends on how
many bytes we wrote.
If the size was 64GB or greater, then we actually overflowed
digits into the mtime field, meaning our value was
effectively right-shifted by those lost octal digits. And
this patch is again a strict improvement over that.
But if the size was between 8GB and 64GB, then our 12-byte
field held all of the actual digits, and only our NUL
terminator overflowed. According to POSIX, there should be a
NUL or space at the end of the field. However, GNU tar seems
to be lenient here, and will correctly parse a size up 64GB
(minus one) from the field. So sizes in this range might
have just worked, depending on the implementation reading
the tarfile.
This patch is mostly still an improvement there, as the 8GB
limit is specifically mentioned in POSIX as the correct
limit. But it's possible that it could be a regression
(versus the pre-f2f0267 state) if all of the following are
true:
1. You have a file between 8GB and 64GB.
2. Your tar implementation _doesn't_ know about pax
extended headers.
3. Your tar implementation _does_ parse 12-byte sizes from
the ustar header without a delimiter.
It's probably not worth worrying about such an obscure set
of conditions, but I'm documenting it here just in case.
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:16 +00:00
|
|
|
|
2006-09-24 15:31:10 +00:00
|
|
|
/* writes out the whole block, but only if it is full */
|
|
|
|
|
static void write_if_needed(void)
|
|
|
|
|
{
|
|
|
|
|
if (offset == BLOCKSIZE) {
|
|
|
|
|
write_or_die(1, block, BLOCKSIZE);
|
|
|
|
|
offset = 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* queues up writes, so that all our write(2) calls write exactly one
|
|
|
|
|
* full block; pads writes to RECORDSIZE
|
|
|
|
|
*/
|
2012-05-03 01:51:04 +00:00
|
|
|
static void do_write_blocked(const void *data, unsigned long size)
|
2006-09-24 15:31:10 +00:00
|
|
|
{
|
|
|
|
|
const char *buf = data;
|
|
|
|
|
|
|
|
|
|
if (offset) {
|
|
|
|
|
unsigned long chunk = BLOCKSIZE - offset;
|
|
|
|
|
if (size < chunk)
|
|
|
|
|
chunk = size;
|
|
|
|
|
memcpy(block + offset, buf, chunk);
|
|
|
|
|
size -= chunk;
|
|
|
|
|
offset += chunk;
|
|
|
|
|
buf += chunk;
|
|
|
|
|
write_if_needed();
|
|
|
|
|
}
|
|
|
|
|
while (size >= BLOCKSIZE) {
|
|
|
|
|
write_or_die(1, buf, BLOCKSIZE);
|
|
|
|
|
size -= BLOCKSIZE;
|
|
|
|
|
buf += BLOCKSIZE;
|
|
|
|
|
}
|
|
|
|
|
if (size) {
|
|
|
|
|
memcpy(block + offset, buf, size);
|
|
|
|
|
offset += size;
|
|
|
|
|
}
|
2012-05-03 01:51:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void finish_record(void)
|
|
|
|
|
{
|
|
|
|
|
unsigned long tail;
|
2006-09-24 15:31:10 +00:00
|
|
|
tail = offset % RECORDSIZE;
|
|
|
|
|
if (tail) {
|
|
|
|
|
memset(block + offset, 0, RECORDSIZE - tail);
|
|
|
|
|
offset += RECORDSIZE - tail;
|
|
|
|
|
}
|
|
|
|
|
write_if_needed();
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-03 01:51:04 +00:00
|
|
|
static void write_blocked(const void *data, unsigned long size)
|
|
|
|
|
{
|
|
|
|
|
do_write_blocked(data, size);
|
|
|
|
|
finish_record();
|
|
|
|
|
}
|
|
|
|
|
|
2006-09-24 15:31:10 +00:00
|
|
|
/*
|
|
|
|
|
* The end of tar archives is marked by 2*512 nul bytes and after that
|
|
|
|
|
* follows the rest of the block (if any).
|
|
|
|
|
*/
|
|
|
|
|
static void write_trailer(void)
|
|
|
|
|
{
|
|
|
|
|
int tail = BLOCKSIZE - offset;
|
|
|
|
|
memset(block + offset, 0, tail);
|
|
|
|
|
write_or_die(1, block, BLOCKSIZE);
|
|
|
|
|
if (tail < 2 * RECORDSIZE) {
|
|
|
|
|
memset(block, 0, offset);
|
|
|
|
|
write_or_die(1, block, BLOCKSIZE);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-03 01:51:04 +00:00
|
|
|
/*
|
|
|
|
|
* queues up writes, so that all our write(2) calls write exactly one
|
|
|
|
|
* full block; pads writes to RECORDSIZE
|
|
|
|
|
*/
|
|
|
|
|
static int stream_blocked(const unsigned char *sha1)
|
|
|
|
|
{
|
|
|
|
|
struct git_istream *st;
|
|
|
|
|
enum object_type type;
|
|
|
|
|
unsigned long sz;
|
|
|
|
|
char buf[BLOCKSIZE];
|
|
|
|
|
ssize_t readlen;
|
|
|
|
|
|
|
|
|
|
st = open_istream(sha1, &type, &sz, NULL);
|
|
|
|
|
if (!st)
|
|
|
|
|
return error("cannot stream blob %s", sha1_to_hex(sha1));
|
|
|
|
|
for (;;) {
|
|
|
|
|
readlen = read_istream(st, buf, sizeof(buf));
|
|
|
|
|
if (readlen <= 0)
|
|
|
|
|
break;
|
|
|
|
|
do_write_blocked(buf, readlen);
|
|
|
|
|
}
|
|
|
|
|
close_istream(st);
|
|
|
|
|
if (!readlen)
|
|
|
|
|
finish_record();
|
|
|
|
|
return readlen;
|
|
|
|
|
}
|
|
|
|
|
|
2006-09-24 15:31:10 +00:00
|
|
|
/*
|
|
|
|
|
* pax extended header records have the format "%u %s=%s\n". %u contains
|
|
|
|
|
* the size of the whole string (including the %u), the first %s is the
|
|
|
|
|
* keyword, the second one is the value. This function constructs such a
|
|
|
|
|
* string and appends it to a struct strbuf.
|
|
|
|
|
*/
|
|
|
|
|
static void strbuf_append_ext_header(struct strbuf *sb, const char *keyword,
|
|
|
|
|
const char *value, unsigned int valuelen)
|
|
|
|
|
{
|
2007-09-06 11:20:06 +00:00
|
|
|
int len, tmp;
|
2006-09-24 15:31:10 +00:00
|
|
|
|
|
|
|
|
/* "%u %s=%s\n" */
|
|
|
|
|
len = 1 + 1 + strlen(keyword) + 1 + valuelen + 1;
|
|
|
|
|
for (tmp = len; tmp > 9; tmp /= 10)
|
|
|
|
|
len++;
|
|
|
|
|
|
2007-09-06 11:20:06 +00:00
|
|
|
strbuf_grow(sb, len);
|
|
|
|
|
strbuf_addf(sb, "%u %s=", len, keyword);
|
|
|
|
|
strbuf_add(sb, value, valuelen);
|
|
|
|
|
strbuf_addch(sb, '\n');
|
2006-09-24 15:31:10 +00:00
|
|
|
}
|
|
|
|
|
|
archive-tar: write extended headers for file sizes >= 8GB
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
077777777777, or 1 byte short of 8GB. The correct solution
for a larger file, according to POSIX.1-2001, is to add an
extended pax header, similar to how we handle long
filenames. This patch does that, and writes zero for the
size field in the ustar header (the last bit is not
mentioned by POSIX, but it matches how GNU tar behaves with
--format=pax).
This should be a strict improvement over the current
behavior, which is to die in xsnprintf with a "BUG".
However, there's some interesting history here.
Prior to f2f0267 (archive-tar: use xsnprintf for trivial
formatting, 2015-09-24), we silently overflowed the "size"
field. The extra bytes ended up in the "mtime" field of the
header, which was then immediately written itself,
overwriting our extra bytes. What that means depends on how
many bytes we wrote.
If the size was 64GB or greater, then we actually overflowed
digits into the mtime field, meaning our value was
effectively right-shifted by those lost octal digits. And
this patch is again a strict improvement over that.
But if the size was between 8GB and 64GB, then our 12-byte
field held all of the actual digits, and only our NUL
terminator overflowed. According to POSIX, there should be a
NUL or space at the end of the field. However, GNU tar seems
to be lenient here, and will correctly parse a size up 64GB
(minus one) from the field. So sizes in this range might
have just worked, depending on the implementation reading
the tarfile.
This patch is mostly still an improvement there, as the 8GB
limit is specifically mentioned in POSIX as the correct
limit. But it's possible that it could be a regression
(versus the pre-f2f0267 state) if all of the following are
true:
1. You have a file between 8GB and 64GB.
2. Your tar implementation _doesn't_ know about pax
extended headers.
3. Your tar implementation _does_ parse 12-byte sizes from
the ustar header without a delimiter.
It's probably not worth worrying about such an obscure set
of conditions, but I'm documenting it here just in case.
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:16 +00:00
|
|
|
/*
|
|
|
|
|
* Like strbuf_append_ext_header, but for numeric values.
|
|
|
|
|
*/
|
|
|
|
|
static void strbuf_append_ext_header_uint(struct strbuf *sb,
|
|
|
|
|
const char *keyword,
|
|
|
|
|
uintmax_t value)
|
|
|
|
|
{
|
|
|
|
|
char buf[40]; /* big enough for 2^128 in decimal, plus NUL */
|
|
|
|
|
int len;
|
|
|
|
|
|
|
|
|
|
len = xsnprintf(buf, sizeof(buf), "%"PRIuMAX, value);
|
|
|
|
|
strbuf_append_ext_header(sb, keyword, buf, len);
|
|
|
|
|
}
|
|
|
|
|
|
2006-09-24 15:31:10 +00:00
|
|
|
static unsigned int ustar_header_chksum(const struct ustar_header *header)
|
|
|
|
|
{
|
2012-06-13 17:42:25 +00:00
|
|
|
const unsigned char *p = (const unsigned char *)header;
|
2006-09-24 15:31:10 +00:00
|
|
|
unsigned int chksum = 0;
|
2012-06-13 17:42:25 +00:00
|
|
|
while (p < (const unsigned char *)header->chksum)
|
2006-09-24 15:31:10 +00:00
|
|
|
chksum += *p++;
|
|
|
|
|
chksum += sizeof(header->chksum) * ' ';
|
|
|
|
|
p += sizeof(header->chksum);
|
2012-06-13 17:42:25 +00:00
|
|
|
while (p < (const unsigned char *)header + sizeof(struct ustar_header))
|
2006-09-24 15:31:10 +00:00
|
|
|
chksum += *p++;
|
|
|
|
|
return chksum;
|
|
|
|
|
}
|
|
|
|
|
|
2008-07-14 19:22:24 +00:00
|
|
|
static size_t get_path_prefix(const char *path, size_t pathlen, size_t maxlen)
|
2006-09-24 15:31:10 +00:00
|
|
|
{
|
2008-07-14 19:22:24 +00:00
|
|
|
size_t i = pathlen;
|
2013-01-05 22:49:54 +00:00
|
|
|
if (i > 1 && path[i - 1] == '/')
|
|
|
|
|
i--;
|
2006-09-24 15:31:10 +00:00
|
|
|
if (i > maxlen)
|
|
|
|
|
i = maxlen;
|
|
|
|
|
do {
|
|
|
|
|
i--;
|
2008-07-14 19:22:24 +00:00
|
|
|
} while (i > 0 && path[i] != '/');
|
2006-09-24 15:31:10 +00:00
|
|
|
return i;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-03 01:51:01 +00:00
|
|
|
static void prepare_header(struct archiver_args *args,
|
|
|
|
|
struct ustar_header *header,
|
|
|
|
|
unsigned int mode, unsigned long size)
|
|
|
|
|
{
|
archive-tar: use xsnprintf for trivial formatting
When we generate tar headers, we sprintf() values directly
into a struct with the fixed-size header values. For the
most part this is fine, as we are formatting small values
(e.g., the octal format of "mode & 0x7777" is of fixed
length). But it's still a good idea to use xsnprintf here.
It communicates to readers what our expectation is, and it
provides a run-time check that we are not overflowing the
buffers.
The one exception here is the mtime, which comes from the
epoch time of the commit we are archiving. For sane values,
this fits into the 12-byte value allocated in the header.
But since git can handle 64-bit times, if I claim to be a
visitor from the year 10,000 AD, I can overflow the buffer.
This turns out to be harmless, as we simply overflow into
the chksum field, which is then overwritten.
This case is also best as an xsnprintf. It should never come
up, short of extremely malformed dates, and in that case we
are probably better off dying than silently truncating the
date value (and we cannot expand the size of the buffer,
since it is dictated by the ustar format). Our friends in
the year 5138 (when we legitimately flip to a 12-digit
epoch) can deal with that problem then.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-24 21:06:24 +00:00
|
|
|
xsnprintf(header->mode, sizeof(header->mode), "%07o", mode & 07777);
|
|
|
|
|
xsnprintf(header->size, sizeof(header->size), "%011lo", S_ISREG(mode) ? size : 0);
|
|
|
|
|
xsnprintf(header->mtime, sizeof(header->mtime), "%011lo", (unsigned long) args->time);
|
2012-05-03 01:51:01 +00:00
|
|
|
|
archive-tar: use xsnprintf for trivial formatting
When we generate tar headers, we sprintf() values directly
into a struct with the fixed-size header values. For the
most part this is fine, as we are formatting small values
(e.g., the octal format of "mode & 0x7777" is of fixed
length). But it's still a good idea to use xsnprintf here.
It communicates to readers what our expectation is, and it
provides a run-time check that we are not overflowing the
buffers.
The one exception here is the mtime, which comes from the
epoch time of the commit we are archiving. For sane values,
this fits into the 12-byte value allocated in the header.
But since git can handle 64-bit times, if I claim to be a
visitor from the year 10,000 AD, I can overflow the buffer.
This turns out to be harmless, as we simply overflow into
the chksum field, which is then overwritten.
This case is also best as an xsnprintf. It should never come
up, short of extremely malformed dates, and in that case we
are probably better off dying than silently truncating the
date value (and we cannot expand the size of the buffer,
since it is dictated by the ustar format). Our friends in
the year 5138 (when we legitimately flip to a 12-digit
epoch) can deal with that problem then.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-24 21:06:24 +00:00
|
|
|
xsnprintf(header->uid, sizeof(header->uid), "%07o", 0);
|
|
|
|
|
xsnprintf(header->gid, sizeof(header->gid), "%07o", 0);
|
2012-05-03 01:51:01 +00:00
|
|
|
strlcpy(header->uname, "root", sizeof(header->uname));
|
|
|
|
|
strlcpy(header->gname, "root", sizeof(header->gname));
|
archive-tar: use xsnprintf for trivial formatting
When we generate tar headers, we sprintf() values directly
into a struct with the fixed-size header values. For the
most part this is fine, as we are formatting small values
(e.g., the octal format of "mode & 0x7777" is of fixed
length). But it's still a good idea to use xsnprintf here.
It communicates to readers what our expectation is, and it
provides a run-time check that we are not overflowing the
buffers.
The one exception here is the mtime, which comes from the
epoch time of the commit we are archiving. For sane values,
this fits into the 12-byte value allocated in the header.
But since git can handle 64-bit times, if I claim to be a
visitor from the year 10,000 AD, I can overflow the buffer.
This turns out to be harmless, as we simply overflow into
the chksum field, which is then overwritten.
This case is also best as an xsnprintf. It should never come
up, short of extremely malformed dates, and in that case we
are probably better off dying than silently truncating the
date value (and we cannot expand the size of the buffer,
since it is dictated by the ustar format). Our friends in
the year 5138 (when we legitimately flip to a 12-digit
epoch) can deal with that problem then.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-24 21:06:24 +00:00
|
|
|
xsnprintf(header->devmajor, sizeof(header->devmajor), "%07o", 0);
|
|
|
|
|
xsnprintf(header->devminor, sizeof(header->devminor), "%07o", 0);
|
2012-05-03 01:51:01 +00:00
|
|
|
|
|
|
|
|
memcpy(header->magic, "ustar", 6);
|
|
|
|
|
memcpy(header->version, "00", 2);
|
|
|
|
|
|
2016-05-26 04:28:08 +00:00
|
|
|
xsnprintf(header->chksum, sizeof(header->chksum), "%07o", ustar_header_chksum(header));
|
2012-05-03 01:51:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int write_extended_header(struct archiver_args *args,
|
|
|
|
|
const unsigned char *sha1,
|
|
|
|
|
const void *buffer, unsigned long size)
|
|
|
|
|
{
|
|
|
|
|
struct ustar_header header;
|
|
|
|
|
unsigned int mode;
|
|
|
|
|
memset(&header, 0, sizeof(header));
|
|
|
|
|
*header.typeflag = TYPEFLAG_EXT_HEADER;
|
2014-10-20 19:04:46 +00:00
|
|
|
mode = 0100666;
|
archive-tar: use xsnprintf for trivial formatting
When we generate tar headers, we sprintf() values directly
into a struct with the fixed-size header values. For the
most part this is fine, as we are formatting small values
(e.g., the octal format of "mode & 0x7777" is of fixed
length). But it's still a good idea to use xsnprintf here.
It communicates to readers what our expectation is, and it
provides a run-time check that we are not overflowing the
buffers.
The one exception here is the mtime, which comes from the
epoch time of the commit we are archiving. For sane values,
this fits into the 12-byte value allocated in the header.
But since git can handle 64-bit times, if I claim to be a
visitor from the year 10,000 AD, I can overflow the buffer.
This turns out to be harmless, as we simply overflow into
the chksum field, which is then overwritten.
This case is also best as an xsnprintf. It should never come
up, short of extremely malformed dates, and in that case we
are probably better off dying than silently truncating the
date value (and we cannot expand the size of the buffer,
since it is dictated by the ustar format). Our friends in
the year 5138 (when we legitimately flip to a 12-digit
epoch) can deal with that problem then.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-24 21:06:24 +00:00
|
|
|
xsnprintf(header.name, sizeof(header.name), "%s.paxheader", sha1_to_hex(sha1));
|
2012-05-03 01:51:01 +00:00
|
|
|
prepare_header(args, &header, mode, size);
|
|
|
|
|
write_blocked(&header, sizeof(header));
|
|
|
|
|
write_blocked(buffer, size);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-07-14 19:22:24 +00:00
|
|
|
static int write_tar_entry(struct archiver_args *args,
|
2012-05-03 01:51:03 +00:00
|
|
|
const unsigned char *sha1,
|
|
|
|
|
const char *path, size_t pathlen,
|
|
|
|
|
unsigned int mode)
|
2006-09-24 15:31:10 +00:00
|
|
|
{
|
|
|
|
|
struct ustar_header header;
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf ext_header = STRBUF_INIT;
|
2012-05-03 01:51:03 +00:00
|
|
|
unsigned int old_mode = mode;
|
archive-tar: write extended headers for file sizes >= 8GB
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
077777777777, or 1 byte short of 8GB. The correct solution
for a larger file, according to POSIX.1-2001, is to add an
extended pax header, similar to how we handle long
filenames. This patch does that, and writes zero for the
size field in the ustar header (the last bit is not
mentioned by POSIX, but it matches how GNU tar behaves with
--format=pax).
This should be a strict improvement over the current
behavior, which is to die in xsnprintf with a "BUG".
However, there's some interesting history here.
Prior to f2f0267 (archive-tar: use xsnprintf for trivial
formatting, 2015-09-24), we silently overflowed the "size"
field. The extra bytes ended up in the "mtime" field of the
header, which was then immediately written itself,
overwriting our extra bytes. What that means depends on how
many bytes we wrote.
If the size was 64GB or greater, then we actually overflowed
digits into the mtime field, meaning our value was
effectively right-shifted by those lost octal digits. And
this patch is again a strict improvement over that.
But if the size was between 8GB and 64GB, then our 12-byte
field held all of the actual digits, and only our NUL
terminator overflowed. According to POSIX, there should be a
NUL or space at the end of the field. However, GNU tar seems
to be lenient here, and will correctly parse a size up 64GB
(minus one) from the field. So sizes in this range might
have just worked, depending on the implementation reading
the tarfile.
This patch is mostly still an improvement there, as the 8GB
limit is specifically mentioned in POSIX as the correct
limit. But it's possible that it could be a regression
(versus the pre-f2f0267 state) if all of the following are
true:
1. You have a file between 8GB and 64GB.
2. Your tar implementation _doesn't_ know about pax
extended headers.
3. Your tar implementation _does_ parse 12-byte sizes from
the ustar header without a delimiter.
It's probably not worth worrying about such an obscure set
of conditions, but I'm documenting it here just in case.
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:16 +00:00
|
|
|
unsigned long size, size_in_header;
|
2012-05-03 01:51:03 +00:00
|
|
|
void *buffer;
|
2008-07-14 19:22:24 +00:00
|
|
|
int err = 0;
|
2006-09-24 15:31:10 +00:00
|
|
|
|
|
|
|
|
memset(&header, 0, sizeof(header));
|
|
|
|
|
|
2012-05-03 01:51:02 +00:00
|
|
|
if (S_ISDIR(mode) || S_ISGITLINK(mode)) {
|
|
|
|
|
*header.typeflag = TYPEFLAG_DIR;
|
|
|
|
|
mode = (mode | 0777) & ~tar_umask;
|
|
|
|
|
} else if (S_ISLNK(mode)) {
|
|
|
|
|
*header.typeflag = TYPEFLAG_LNK;
|
|
|
|
|
mode |= 0777;
|
|
|
|
|
} else if (S_ISREG(mode)) {
|
|
|
|
|
*header.typeflag = TYPEFLAG_REG;
|
|
|
|
|
mode = (mode | ((mode & 0100) ? 0777 : 0666)) & ~tar_umask;
|
2006-09-24 15:31:10 +00:00
|
|
|
} else {
|
2012-05-03 01:51:02 +00:00
|
|
|
return error("unsupported file mode: 0%o (SHA1: %s)",
|
|
|
|
|
mode, sha1_to_hex(sha1));
|
|
|
|
|
}
|
|
|
|
|
if (pathlen > sizeof(header.name)) {
|
|
|
|
|
size_t plen = get_path_prefix(path, pathlen,
|
|
|
|
|
sizeof(header.prefix));
|
|
|
|
|
size_t rest = pathlen - plen - 1;
|
|
|
|
|
if (plen > 0 && rest <= sizeof(header.name)) {
|
|
|
|
|
memcpy(header.prefix, path, plen);
|
2015-09-24 21:03:49 +00:00
|
|
|
memcpy(header.name, path + plen + 1, rest);
|
2006-09-24 15:31:10 +00:00
|
|
|
} else {
|
archive-tar: use xsnprintf for trivial formatting
When we generate tar headers, we sprintf() values directly
into a struct with the fixed-size header values. For the
most part this is fine, as we are formatting small values
(e.g., the octal format of "mode & 0x7777" is of fixed
length). But it's still a good idea to use xsnprintf here.
It communicates to readers what our expectation is, and it
provides a run-time check that we are not overflowing the
buffers.
The one exception here is the mtime, which comes from the
epoch time of the commit we are archiving. For sane values,
this fits into the 12-byte value allocated in the header.
But since git can handle 64-bit times, if I claim to be a
visitor from the year 10,000 AD, I can overflow the buffer.
This turns out to be harmless, as we simply overflow into
the chksum field, which is then overwritten.
This case is also best as an xsnprintf. It should never come
up, short of extremely malformed dates, and in that case we
are probably better off dying than silently truncating the
date value (and we cannot expand the size of the buffer,
since it is dictated by the ustar format). Our friends in
the year 5138 (when we legitimately flip to a 12-digit
epoch) can deal with that problem then.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-24 21:06:24 +00:00
|
|
|
xsnprintf(header.name, sizeof(header.name), "%s.data",
|
|
|
|
|
sha1_to_hex(sha1));
|
2012-05-03 01:51:02 +00:00
|
|
|
strbuf_append_ext_header(&ext_header, "path",
|
|
|
|
|
path, pathlen);
|
2006-09-24 15:31:10 +00:00
|
|
|
}
|
2012-05-03 01:51:02 +00:00
|
|
|
} else
|
|
|
|
|
memcpy(header.name, path, pathlen);
|
2006-09-24 15:31:10 +00:00
|
|
|
|
2012-05-03 01:51:04 +00:00
|
|
|
if (S_ISREG(mode) && !args->convert &&
|
|
|
|
|
sha1_object_info(sha1, &size) == OBJ_BLOB &&
|
|
|
|
|
size > big_file_threshold)
|
|
|
|
|
buffer = NULL;
|
|
|
|
|
else if (S_ISLNK(mode) || S_ISREG(mode)) {
|
2012-05-03 01:51:03 +00:00
|
|
|
enum object_type type;
|
|
|
|
|
buffer = sha1_file_to_archive(args, path, sha1, old_mode, &type, &size);
|
|
|
|
|
if (!buffer)
|
|
|
|
|
return error("cannot read %s", sha1_to_hex(sha1));
|
|
|
|
|
} else {
|
|
|
|
|
buffer = NULL;
|
|
|
|
|
size = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (S_ISLNK(mode)) {
|
2006-09-24 15:31:10 +00:00
|
|
|
if (size > sizeof(header.linkname)) {
|
archive-tar: use xsnprintf for trivial formatting
When we generate tar headers, we sprintf() values directly
into a struct with the fixed-size header values. For the
most part this is fine, as we are formatting small values
(e.g., the octal format of "mode & 0x7777" is of fixed
length). But it's still a good idea to use xsnprintf here.
It communicates to readers what our expectation is, and it
provides a run-time check that we are not overflowing the
buffers.
The one exception here is the mtime, which comes from the
epoch time of the commit we are archiving. For sane values,
this fits into the 12-byte value allocated in the header.
But since git can handle 64-bit times, if I claim to be a
visitor from the year 10,000 AD, I can overflow the buffer.
This turns out to be harmless, as we simply overflow into
the chksum field, which is then overwritten.
This case is also best as an xsnprintf. It should never come
up, short of extremely malformed dates, and in that case we
are probably better off dying than silently truncating the
date value (and we cannot expand the size of the buffer,
since it is dictated by the ustar format). Our friends in
the year 5138 (when we legitimately flip to a 12-digit
epoch) can deal with that problem then.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-24 21:06:24 +00:00
|
|
|
xsnprintf(header.linkname, sizeof(header.linkname),
|
|
|
|
|
"see %s.paxheader", sha1_to_hex(sha1));
|
2006-09-24 15:31:10 +00:00
|
|
|
strbuf_append_ext_header(&ext_header, "linkpath",
|
|
|
|
|
buffer, size);
|
|
|
|
|
} else
|
|
|
|
|
memcpy(header.linkname, buffer, size);
|
|
|
|
|
}
|
|
|
|
|
|
archive-tar: write extended headers for file sizes >= 8GB
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
077777777777, or 1 byte short of 8GB. The correct solution
for a larger file, according to POSIX.1-2001, is to add an
extended pax header, similar to how we handle long
filenames. This patch does that, and writes zero for the
size field in the ustar header (the last bit is not
mentioned by POSIX, but it matches how GNU tar behaves with
--format=pax).
This should be a strict improvement over the current
behavior, which is to die in xsnprintf with a "BUG".
However, there's some interesting history here.
Prior to f2f0267 (archive-tar: use xsnprintf for trivial
formatting, 2015-09-24), we silently overflowed the "size"
field. The extra bytes ended up in the "mtime" field of the
header, which was then immediately written itself,
overwriting our extra bytes. What that means depends on how
many bytes we wrote.
If the size was 64GB or greater, then we actually overflowed
digits into the mtime field, meaning our value was
effectively right-shifted by those lost octal digits. And
this patch is again a strict improvement over that.
But if the size was between 8GB and 64GB, then our 12-byte
field held all of the actual digits, and only our NUL
terminator overflowed. According to POSIX, there should be a
NUL or space at the end of the field. However, GNU tar seems
to be lenient here, and will correctly parse a size up 64GB
(minus one) from the field. So sizes in this range might
have just worked, depending on the implementation reading
the tarfile.
This patch is mostly still an improvement there, as the 8GB
limit is specifically mentioned in POSIX as the correct
limit. But it's possible that it could be a regression
(versus the pre-f2f0267 state) if all of the following are
true:
1. You have a file between 8GB and 64GB.
2. Your tar implementation _doesn't_ know about pax
extended headers.
3. Your tar implementation _does_ parse 12-byte sizes from
the ustar header without a delimiter.
It's probably not worth worrying about such an obscure set
of conditions, but I'm documenting it here just in case.
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:16 +00:00
|
|
|
size_in_header = size;
|
|
|
|
|
if (S_ISREG(mode) && size > USTAR_MAX_SIZE) {
|
|
|
|
|
size_in_header = 0;
|
|
|
|
|
strbuf_append_ext_header_uint(&ext_header, "size", size);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
prepare_header(args, &header, mode, size_in_header);
|
2006-09-24 15:31:10 +00:00
|
|
|
|
|
|
|
|
if (ext_header.len > 0) {
|
2012-05-03 01:51:01 +00:00
|
|
|
err = write_extended_header(args, sha1, ext_header.buf,
|
|
|
|
|
ext_header.len);
|
2012-05-03 01:51:03 +00:00
|
|
|
if (err) {
|
|
|
|
|
free(buffer);
|
2008-07-14 19:22:24 +00:00
|
|
|
return err;
|
2012-05-03 01:51:03 +00:00
|
|
|
}
|
2006-09-24 15:31:10 +00:00
|
|
|
}
|
2007-09-06 11:20:06 +00:00
|
|
|
strbuf_release(&ext_header);
|
2006-09-24 15:31:10 +00:00
|
|
|
write_blocked(&header, sizeof(header));
|
2012-05-03 01:51:04 +00:00
|
|
|
if (S_ISREG(mode) && size > 0) {
|
|
|
|
|
if (buffer)
|
|
|
|
|
write_blocked(buffer, size);
|
|
|
|
|
else
|
|
|
|
|
err = stream_blocked(sha1);
|
|
|
|
|
}
|
2012-05-03 01:51:03 +00:00
|
|
|
free(buffer);
|
2008-07-14 19:22:24 +00:00
|
|
|
return err;
|
2006-09-24 15:31:10 +00:00
|
|
|
}
|
|
|
|
|
|
2016-06-30 09:09:26 +00:00
|
|
|
static void write_global_extended_header(struct archiver_args *args)
|
2006-09-24 15:31:10 +00:00
|
|
|
{
|
2008-07-14 19:22:24 +00:00
|
|
|
const unsigned char *sha1 = args->commit_sha1;
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf ext_header = STRBUF_INIT;
|
2012-05-03 01:51:01 +00:00
|
|
|
struct ustar_header header;
|
|
|
|
|
unsigned int mode;
|
2007-09-06 11:20:06 +00:00
|
|
|
|
archive-tar: write extended headers for far-future mtime
The ustar format represents timestamps as seconds since the
epoch, but only has room to store 11 octal digits. To
express anything larger, we need to use an extended header.
This is exactly the same case we fixed for the size field in
the previous commit, and the solution here follows the same
pattern.
This is even mentioned as an issue in f2f0267 (archive-tar:
use xsnprintf for trivial formatting, 2015-09-24), but since
it only affected things far in the future, it wasn't deemed
worth dealing with. But note that my calculations claiming
thousands of years were off there; because our xsnprintf
produces a NUL byte, we only have until the year 2242 to fix
this.
Given that this is just around the corner (geologically
speaking, anyway), and because it's easy to fix, let's just
make it work. Unlike the previous fix for "size", where we
had to write an individual extended header for each file, we
can write one global header (since we have only one mtime
for the whole archive).
There's a slight bit of trickiness there. We may already be
writing a global header with a "comment" field for the
commit sha1. So we need to write our new field into the same
header. To do this, we push the decision of whether to write
such a header down into write_global_extended_header(),
which will now assemble the header as it sees fit, and will
return early if we have nothing to write (in practice, we'll
only have a large mtime if it comes from a commit, but this
makes it also work if you set your system clock ahead such
that time() returns a huge value).
Note that we don't (and never did) handle negative
timestamps (i.e., before 1970). This would probably not be
too hard to support in the same way, but since git does not
support negative timestamps at all, I didn't bother here.
After writing the extended header, we munge the timestamp in
the ustar headers to the maximum-allowable size. This is
wrong, but it's the least-wrong thing we can provide to a
tar implementation that doesn't understand pax headers (it's
also what GNU tar does).
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:20 +00:00
|
|
|
if (sha1)
|
|
|
|
|
strbuf_append_ext_header(&ext_header, "comment",
|
|
|
|
|
sha1_to_hex(sha1), 40);
|
|
|
|
|
if (args->time > USTAR_MAX_MTIME) {
|
|
|
|
|
strbuf_append_ext_header_uint(&ext_header, "mtime",
|
|
|
|
|
args->time);
|
|
|
|
|
args->time = USTAR_MAX_MTIME;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!ext_header.len)
|
2016-06-30 09:09:26 +00:00
|
|
|
return;
|
archive-tar: write extended headers for far-future mtime
The ustar format represents timestamps as seconds since the
epoch, but only has room to store 11 octal digits. To
express anything larger, we need to use an extended header.
This is exactly the same case we fixed for the size field in
the previous commit, and the solution here follows the same
pattern.
This is even mentioned as an issue in f2f0267 (archive-tar:
use xsnprintf for trivial formatting, 2015-09-24), but since
it only affected things far in the future, it wasn't deemed
worth dealing with. But note that my calculations claiming
thousands of years were off there; because our xsnprintf
produces a NUL byte, we only have until the year 2242 to fix
this.
Given that this is just around the corner (geologically
speaking, anyway), and because it's easy to fix, let's just
make it work. Unlike the previous fix for "size", where we
had to write an individual extended header for each file, we
can write one global header (since we have only one mtime
for the whole archive).
There's a slight bit of trickiness there. We may already be
writing a global header with a "comment" field for the
commit sha1. So we need to write our new field into the same
header. To do this, we push the decision of whether to write
such a header down into write_global_extended_header(),
which will now assemble the header as it sees fit, and will
return early if we have nothing to write (in practice, we'll
only have a large mtime if it comes from a commit, but this
makes it also work if you set your system clock ahead such
that time() returns a huge value).
Note that we don't (and never did) handle negative
timestamps (i.e., before 1970). This would probably not be
too hard to support in the same way, but since git does not
support negative timestamps at all, I didn't bother here.
After writing the extended header, we munge the timestamp in
the ustar headers to the maximum-allowable size. This is
wrong, but it's the least-wrong thing we can provide to a
tar implementation that doesn't understand pax headers (it's
also what GNU tar does).
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 09:09:20 +00:00
|
|
|
|
2012-05-03 01:51:01 +00:00
|
|
|
memset(&header, 0, sizeof(header));
|
|
|
|
|
*header.typeflag = TYPEFLAG_GLOBAL_HEADER;
|
2014-10-20 19:04:46 +00:00
|
|
|
mode = 0100666;
|
2015-09-24 21:06:08 +00:00
|
|
|
xsnprintf(header.name, sizeof(header.name), "pax_global_header");
|
2012-05-03 01:51:01 +00:00
|
|
|
prepare_header(args, &header, mode, ext_header.len);
|
|
|
|
|
write_blocked(&header, sizeof(header));
|
|
|
|
|
write_blocked(ext_header.buf, ext_header.len);
|
2007-09-06 11:20:06 +00:00
|
|
|
strbuf_release(&ext_header);
|
2006-09-24 15:31:10 +00:00
|
|
|
}
|
|
|
|
|
|
2011-06-22 01:26:31 +00:00
|
|
|
static struct archiver **tar_filters;
|
|
|
|
|
static int nr_tar_filters;
|
|
|
|
|
static int alloc_tar_filters;
|
|
|
|
|
|
|
|
|
|
static struct archiver *find_tar_filter(const char *name, int len)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < nr_tar_filters; i++) {
|
|
|
|
|
struct archiver *ar = tar_filters[i];
|
|
|
|
|
if (!strncmp(ar->name, name, len) && !ar->name[len])
|
|
|
|
|
return ar;
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int tar_filter_config(const char *var, const char *value, void *data)
|
|
|
|
|
{
|
|
|
|
|
struct archiver *ar;
|
|
|
|
|
const char *name;
|
|
|
|
|
const char *type;
|
|
|
|
|
int namelen;
|
|
|
|
|
|
2013-01-23 06:23:27 +00:00
|
|
|
if (parse_config_key(var, "tar", &name, &namelen, &type) < 0 || !name)
|
2011-06-22 01:26:31 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
ar = find_tar_filter(name, namelen);
|
|
|
|
|
if (!ar) {
|
|
|
|
|
ar = xcalloc(1, sizeof(*ar));
|
|
|
|
|
ar->name = xmemdupz(name, namelen);
|
|
|
|
|
ar->write_archive = write_tar_filter_archive;
|
|
|
|
|
ar->flags = ARCHIVER_WANT_COMPRESSION_LEVELS;
|
|
|
|
|
ALLOC_GROW(tar_filters, nr_tar_filters + 1, alloc_tar_filters);
|
|
|
|
|
tar_filters[nr_tar_filters++] = ar;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!strcmp(type, "command")) {
|
|
|
|
|
if (!value)
|
|
|
|
|
return config_error_nonbool(var);
|
|
|
|
|
free(ar->data);
|
|
|
|
|
ar->data = xstrdup(value);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2011-06-22 03:17:35 +00:00
|
|
|
if (!strcmp(type, "remote")) {
|
|
|
|
|
if (git_config_bool(var, value))
|
|
|
|
|
ar->flags |= ARCHIVER_REMOTE;
|
|
|
|
|
else
|
|
|
|
|
ar->flags &= ~ARCHIVER_REMOTE;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2011-06-22 01:26:31 +00:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2008-05-14 17:46:53 +00:00
|
|
|
static int git_tar_config(const char *var, const char *value, void *cb)
|
2006-09-24 15:31:10 +00:00
|
|
|
{
|
|
|
|
|
if (!strcmp(var, "tar.umask")) {
|
2008-02-09 04:38:22 +00:00
|
|
|
if (value && !strcmp(value, "user")) {
|
2006-09-24 15:31:10 +00:00
|
|
|
tar_umask = umask(0);
|
|
|
|
|
umask(tar_umask);
|
|
|
|
|
} else {
|
|
|
|
|
tar_umask = git_config_int(var, value);
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2011-06-22 01:26:31 +00:00
|
|
|
|
|
|
|
|
return tar_filter_config(var, value, cb);
|
2006-09-24 15:31:10 +00:00
|
|
|
}
|
|
|
|
|
|
2011-06-22 01:24:07 +00:00
|
|
|
static int write_tar_archive(const struct archiver *ar,
|
|
|
|
|
struct archiver_args *args)
|
2006-09-24 15:31:10 +00:00
|
|
|
{
|
2008-07-14 19:22:24 +00:00
|
|
|
int err = 0;
|
2006-09-24 15:31:10 +00:00
|
|
|
|
2016-06-30 09:09:26 +00:00
|
|
|
write_global_extended_header(args);
|
|
|
|
|
err = write_archive_entries(args, write_tar_entry);
|
2008-07-14 19:22:24 +00:00
|
|
|
if (!err)
|
|
|
|
|
write_trailer();
|
|
|
|
|
return err;
|
2006-09-24 15:31:10 +00:00
|
|
|
}
|
2011-06-22 01:23:33 +00:00
|
|
|
|
2011-06-22 01:26:31 +00:00
|
|
|
static int write_tar_filter_archive(const struct archiver *ar,
|
|
|
|
|
struct archiver_args *args)
|
|
|
|
|
{
|
|
|
|
|
struct strbuf cmd = STRBUF_INIT;
|
2014-08-19 19:09:35 +00:00
|
|
|
struct child_process filter = CHILD_PROCESS_INIT;
|
2011-06-22 01:26:31 +00:00
|
|
|
const char *argv[2];
|
|
|
|
|
int r;
|
|
|
|
|
|
|
|
|
|
if (!ar->data)
|
|
|
|
|
die("BUG: tar-filter archiver called with no filter defined");
|
|
|
|
|
|
|
|
|
|
strbuf_addstr(&cmd, ar->data);
|
|
|
|
|
if (args->compression_level >= 0)
|
|
|
|
|
strbuf_addf(&cmd, " -%d", args->compression_level);
|
|
|
|
|
|
|
|
|
|
argv[0] = cmd.buf;
|
|
|
|
|
argv[1] = NULL;
|
|
|
|
|
filter.argv = argv;
|
|
|
|
|
filter.use_shell = 1;
|
|
|
|
|
filter.in = -1;
|
|
|
|
|
|
|
|
|
|
if (start_command(&filter) < 0)
|
|
|
|
|
die_errno("unable to start '%s' filter", argv[0]);
|
|
|
|
|
close(1);
|
|
|
|
|
if (dup2(filter.in, 1) < 0)
|
|
|
|
|
die_errno("unable to redirect descriptor");
|
|
|
|
|
close(filter.in);
|
|
|
|
|
|
|
|
|
|
r = write_tar_archive(ar, args);
|
|
|
|
|
|
|
|
|
|
close(1);
|
|
|
|
|
if (finish_command(&filter) != 0)
|
|
|
|
|
die("'%s' filter reported error", argv[0]);
|
|
|
|
|
|
|
|
|
|
strbuf_release(&cmd);
|
|
|
|
|
return r;
|
|
|
|
|
}
|
|
|
|
|
|
2011-06-22 01:23:33 +00:00
|
|
|
static struct archiver tar_archiver = {
|
|
|
|
|
"tar",
|
|
|
|
|
write_tar_archive,
|
2011-06-22 03:17:35 +00:00
|
|
|
ARCHIVER_REMOTE
|
2011-06-22 01:23:33 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
void init_tar_archiver(void)
|
|
|
|
|
{
|
2011-06-22 01:26:31 +00:00
|
|
|
int i;
|
2011-06-22 01:23:33 +00:00
|
|
|
register_archiver(&tar_archiver);
|
2011-06-22 01:26:31 +00:00
|
|
|
|
2011-06-22 01:27:35 +00:00
|
|
|
tar_filter_config("tar.tgz.command", "gzip -cn", NULL);
|
2011-06-22 03:17:35 +00:00
|
|
|
tar_filter_config("tar.tgz.remote", "true", NULL);
|
2011-06-22 01:27:35 +00:00
|
|
|
tar_filter_config("tar.tar.gz.command", "gzip -cn", NULL);
|
2011-06-22 03:17:35 +00:00
|
|
|
tar_filter_config("tar.tar.gz.remote", "true", NULL);
|
2011-06-22 01:23:33 +00:00
|
|
|
git_config(git_tar_config, NULL);
|
2011-06-22 01:26:31 +00:00
|
|
|
for (i = 0; i < nr_tar_filters; i++) {
|
|
|
|
|
/* omit any filters that never had a command configured */
|
|
|
|
|
if (tar_filters[i]->data)
|
|
|
|
|
register_archiver(tar_filters[i]);
|
|
|
|
|
}
|
2011-06-22 01:23:33 +00:00
|
|
|
}
|