Debian Bug report logs - #743227
"git -c transfer.fsckobjects=true clone https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware" fails

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: submit@bugs.debian.org

Subject: "git -c transfer.fsckobjects=true clone https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware" fails

Date: Mon, 31 Mar 2014 10:05:43 -0700

Package: git
Version: 1:2.0~next.20140318-1
Severity: important
Tags: upstream

  $ git -c transfer.fsckobjects=true clone https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware
  Cloning into 'linux-firmware'...
  remote: Counting objects: 2518, done.
  remote: Compressing objects: 100% (1168/1168), done.
  remote: Total 2518 (delta 1313), reused 2518 (delta 1313)
  error: object 087fbb748f50af6eac2248a445d25d666cc92c78:contains zero-padded file modes
  fatal: Error in object
  fatal: index-pack failed

But:

  $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware
[...]
  $ git fsck
  Checking object directories: 100% (256/256), done.
  warning in tree ff42cbe9e62d5d3e383ca621028bd6554597d5f0: contains zero-padded file modes
  warning in tree a1b6cee91e8ec2d6234662bae82e7311ddebcae4: contains zero-padded file modes
[...]

Should it be a warning or an error?

Message #10 received at 743227@bugs.debian.org (full text, mbox, reply):

From: Stéphane Gourichon <stephane.gourichon@gmail.com>

To: 743227@bugs.debian.org

Subject: Reproduced today on Debian 7.9

Date: Wed, 3 Feb 2016 11:23:21 +0100

Reproduced today on Debian 7.9 Amd64, git 1:1.9.1-1~bpo70+2,
which means that the repository was not fixed in between.

LC_ALL=C git -c transfer.fsckobjects=true clone 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware

Cloning into 'linux-firmware'...
remote: Counting objects: 3966, done.
remote: Total 3966 (delta 0), reused 0 (delta 0)
error: object 087fbb748f50af6eac2248a445d25d666cc92c78:contains 
zero-padded file modes
fatal: Error in object
fatal: index-pack failed

Command exited with non-zero status 128

See also
[git - propagating repo corruption across 
clone](http://git.661346.n2.nabble.com/propagating-repo-corruption-across-clone-td7580504.html)
[#813157 - git: please default fsckobjects to true in transfer, fetch, 
and receive - Debian Bug report 
logs](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813157)

(link reference [git 
integrity - Google Groupes](https://groups.google.com/forum/#!topic/binary-transparency/f-BI4o8HZW0) 
)

-- 
Stéphane Gourichon

Message #15 received at 743227@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Stéphane Gourichon <stephane.gourichon@gmail.com>, 743227@bugs.debian.org

Subject: Re: Bug#743227: Reproduced today on Debian 7.9

Date: Thu, 4 Feb 2016 14:28:27 +0900

On Wed, Feb 03, 2016 at 11:23:21AM +0100, Stéphane Gourichon wrote:
> Reproduced today on Debian 7.9 Amd64, git 1:1.9.1-1~bpo70+2,
> which means that the repository was not fixed in between.

Why would it have been "fixed", when that means changing the tree sha1,
and the commit sha1 of the first commit containing this tree, and all
the child commits?

> LC_ALL=C git -c transfer.fsckobjects=true clone
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware
> 
> Cloning into 'linux-firmware'...
> remote: Counting objects: 3966, done.
> remote: Total 3966 (delta 0), reused 0 (delta 0)
> error: object 087fbb748f50af6eac2248a445d25d666cc92c78:contains zero-padded
> file modes
> fatal: Error in object
> fatal: index-pack failed

Note that what this error means is that that tree contains modes like
040000 instead of 40000. In practice, it doesn't matter, and the tree
was likely generated with some tool using a dulwich version that left
zero-padding on modes or something like that. Git itself, afaict from
a quick glance at the history of cache-tree.c never created such objects
(it's always used %o for the mode) ; and in fact, it looks like it can't
be dulwich either, which always used %04o (which doesn't pad for 40000).
So it must be some other tool.

Mike

Send a report that this bug log contains spam.