Package: git-core
Version: 1:1.6.6.1-1
Severity: important
'git add' will happily corrupt a git repo if it is run while files in
the working directory are being modified. A blob is added to the index
with contents that do not match its SHA1 hash. If the index is then
committed, the corrupt blob cannot be checked out (or is checked out
with incorrect contents, depending on which tool you use to try to get
the file out of git) in the future.
Surprisingly, it's possible to clone, fetch, push, pull, and sometimes
even gc the corrupted repo several times before anyone notices the
corruption. If the affected commit is included in a merge with history
from other git users, the only way to fix it is to rebase (or come up
with a blob whose contents match the affected SHA1 hash somehow).
It is usually possible to retrieve data committed before the corruption
by simply checking out an earlier tree in the affected branch's history.
The following shell code demonstrates this problem. It runs a thread
which continuously modifies a file, and another thread that does
'git commit -am' and 'git fsck' in a continuous loop until corruption
is detected. This might take up to 20 seconds on a slow machine.
#!/bin/sh
set -e
# Create an empty git repo in /tmp/git-test
rm -fr /tmp/git-test
mkdir /tmp/git-test
cd /tmp/git-test
git init
# Create a file named foo and add it to the repo
touch foo
git add foo
# Thread 1: continuously modify foo:
while echo -n .; do
dd if=/dev/urandom of=foo count=1024 bs=1k conv=notrunc
>/dev/null 2>&1
done &
# Thread 2: loop until the repo is corrupted
while git fsck; do
# Note the implied 'git add' in 'commit -a'
# It will do the same with explicit 'git add'
git commit -a -m'Test'
done
# Kill thread 1, we don't need it any more
kill $!
# Success! Well, sort of.
echo Repository is corrupted. Have a nice day.
I discovered this bug accidentally when I was using inotifywait (from
the inotify-tools package) to automatically commit snapshots of a working
directory triggered by write events.
I tested this with a number of kernel versions from 2.6.27 to 2.6.31.
All of them reproduced this problem. I checked this because strace
shows 'git add' doing a mmap(..., MAP_PRIVATE, ...) of its input file,
so I was wondering if there might have been a recent change in mmap()
behavior in either git or the kernel.
git 1.5.6.5 has this problem too, but some of the error messages are
different, and the problem sometimes manifests itself as silent corruption
of other objects (e.g. if someone checks out a corrupt tree and then does
'git add -u' or 'git commit -a', they will include the corrupt data in
their commit).
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (500, 'stable'), (189, 'testing'), (179, 'unstable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31.8-zb64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages git-core depends on:
ii libc6 2.10.2-2 GNU C Library: Shared libraries
ii libcurl3-gnutls 7.18.2-8lenny3 Multi-protocol file transfer libra
ii libdigest-sha1-perl 2.11-2+b1 NIST SHA-1 message digest algorith
ii liberror-perl 0.17-1 Perl module for error/exception ha
ii libexpat1 2.0.1-4+lenny3 XML parsing C library - runtime li
ii perl-modules 5.10.1-9 Core Perl modules
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages git-core recommends:
ii less 418-1 Pager program similar to more
ii openssh-client [ssh-client] 1:5.1p1-5 secure shell client, an rlogin/rsh
ii patch 2.5.9-5 Apply a diff file to an original
ii rsync 3.0.3-2 fast remote file copy program (lik
Versions of packages git-core suggests:
pn git-arch <none> (no description available)
ii git-cvs 1:1.6.6.1-1 fast, scalable, distributed revisi
pn git-daemon-run <none> (no description available)
ii git-doc 1:1.6.6.1-1 fast, scalable, distributed revisi
pn git-email <none> (no description available)
pn git-gui <none> (no description available)
ii git-svn 1:1.6.6.1-1 fast, scalable, distributed revisi
ii gitk 1:1.6.6.1-1 fast, scalable, distributed revisi
pn gitweb <none> (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
