Re: Sources for 3.18-rc1 not uploaded
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Oct 20, 2014, 15:25 UTC
- Message-ID
- <CA+55aFyDuHskYE66rBVL_P-T2pxg6f2m6mUicfz-mk+ysePBxg@mail.gmail.com>
- In-Reply-To
- <20141020115943.GA27144@gmail.com>
Junio, Brian,
it seems that the stability of the "git tar" output is broken.
On Mon, Oct 20, 2014 at 4:59 AM, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
Show 5 quoted lines
> > Looks like 3.18-rc1 upload didn't work: > > This is why the front page still lists 3.17 as the latest mainline. Want > to try again?
Ok, tried again, and failed again.
> If that still doesn't work, you may have to use version 1.7 of git when > generating the tarball and signature -- I recall Greg having a similar > problem in the past.
Ugh, yes, that seems to be it. Current git generates different tar-files than older releases do:
tar-1.7.9.7 tar-cur differ: byte 107, line 1
and a quick bisection shows that it is due to commit 10f343ea814f ("archive: honor tar.umask even for pax headers") in the current git development version.
Junio, quite frankly, I don't think that that fix was a good idea. I'd suggest having a *separate* umask for the pax headers, so that we do not break this long-lasting stability of "git archive" output in ways that are unfixable and not compatible. kernel.org has relied (for a *long* time) on being able to just upload the signature of the resulting tar-file, because both sides can generate the same tar-fiel bit-for-bit.
So instead of using "tar_umask", please make it use "tar_pax_umask", and have that default to 000. Ok?
Something like the attached patch.
Or just revert 10f343ea814f entirely.
Linus
From d5ca7ae0a34e31c48397f59b03ecabda7c5c40b2 Mon Sep 17 00:00:00 2001 From: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon, 20 Oct 2014 08:21:38 -0700 Subject: [PATCH] Don't use the default 'tar.umask' for pax headers
That wasn't the original behavior, and doing so breaks the fact that tar-files are bit-for-bit compatible across git versions.
If you really want to work around broken receiving tar implementations (dubious, we've not needed to do so before), use "[tar] paxumask" in the git config file. Or maybe we could expose some command line flag to do so. But don't break existing format compatibility for dubious gains.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> --- archive-tar.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c index df2f4c8a6437..40139ea4ee4e 100644 --- a/archive-tar.c +++ b/archive-tar.c @@ -14,6 +14,7 @@ static char block[BLOCKSIZE]; static unsigned long offset; static int tar_umask = 002; +static int tar_pax_umask = 000; static int write_tar_filter_archive(const struct archiver *ar, struct archiver_args *args); @@ -192,7 +193,7 @@ static int write_extended_header(struct archiver_args *args, unsigned int mode; memset(&header, 0, sizeof(header)); *header.typeflag = TYPEFLAG_EXT_HEADER; - mode = 0100666 & ~tar_umask; + mode = 0100666 & ~tar_pax_umask; sprintf(header.name, "%s.paxheader", sha1_to_hex(sha1)); prepare_header(args, &header, mode, size); write_blocked(&header, sizeof(header)); @@ -300,7 +301,7 @@ static int write_global_extended_header(struct archiver_args *args) strbuf_append_ext_header(&ext_header, "comment", sha1_to_hex(sha1), 40); memset(&header, 0, sizeof(header)); *header.typeflag = TYPEFLAG_GLOBAL_HEADER; - mode = 0100666 & ~tar_umask; + mode = 0100666 & ~tar_pax_umask; strcpy(header.name, "pax_global_header"); prepare_header(args, &header, mode, ext_header.len); write_blocked(&header, sizeof(header)); @@ -374,6 +375,15 @@ static int git_tar_config(const char *var, const char *value, void *cb) return 0; } + if (!strcmp(var, "tar.paxumask")) { + if (value && !strcmp(value, "user")) { + tar_pax_umask = umask(0); + } else { + tar_pax_umask = git_config_int(var, value); + } + return 0; + } + return tar_filter_config(var, value, cb); }
-- 2.1.2.330.g565301e