Make sure lockfiles are unlocked when dying on SIGPIPE
We cleaned up lockfiles upon receiving the usual suspects HUP, TERM, QUIT but a wicked user could kill us of asphyxiation by piping our output to a pipe that does not read. Protect ourselves by catching SIGPIPE and clean up the lockfiles as well in such a case. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano committed
Dec 18, 2008 at 17:31 UTC
0693f9ddad3d9af3d3424087557bbddce480ce3f
2 files changed
+18
lockfile.c
+1
@@ -140,6 +140,7 @@ static int lock_file(struct lock_file *lk, const char *path, int flags)
140
signal(SIGHUP, remove_lock_file_on_signal);
141
signal(SIGTERM, remove_lock_file_on_signal);
142
signal(SIGQUIT, remove_lock_file_on_signal);
143
+ signal(SIGPIPE, remove_lock_file_on_signal);
144
atexit(remove_lock_file);
145
}
146
lk->owner = getpid();
t/t3600-rm.sh
+17
@@ -251,4 +251,21 @@ test_expect_success 'refresh index before checking if it is up-to-date' '
251
252
'
253
254
+test_expect_success 'choking "git rm" should not let it die with cruft' '
255
+ git reset -q --hard &&
256
+ H=0000000000000000000000000000000000000000 &&
257
+ i=0 &&
258
+ while test $i -lt 12000
259
+ do
260
+ echo "100644 $H 0 some-file-$i"
261
+ i=$(( $i + 1 ))
262
+ done | git update-index --index-info &&
263
+ git rm -n "some-file-*" | :;
264
+ test -f .git/index.lock
265
+ status=$?
266
+ rm -f .git/index.lock
267
+ git reset -q --hard
268
+ test "$status" != 0
269
+'
270
+
271
test_done