Junio C Hamano <gitster@xxxxxxxxx> writes: > But the nature of breakage caused by such an abuse is rather bad. We will > end up with loose object files, whose names do not match what are stored > and recovered when uncompressed. > > This teaches the index_mem() codepath to be paranoid and hash and compress > the data after reading it in core. The contents hashed may not match the > contents of the file in an insane use case, but at least this way the > result will be internally consistent. With a small fix to the test program earlier in the thread, this seems to protect the repository; I didn't bother to assess the performance impact of the patch, though. Here is the corrected test. -- >8 -- #!/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' || break done # Kill thread 1, we don't need it any more kill $! # Success! Well, sort of. if git fsck then echo Repository is corrupted. Have a nice day. else echo Repository is still healthy. You are stupid. fi -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html