Package: findutils
Version: 4.1.20-6
Followup-For: Bug #90381
Hi,
this patch fixes the reported bug. If any command in the pipe fails,
$LOCATE_DB.n will have a size of <= 10 bytes (0 if frcode fails, 10
on any other command). It keeps the currently available locatedb on
failure instead of detroying it. Due to the nature of the pipes it's
not (easily) possible to report an error unless frcode fails. So we
have to live with the non destructive part.
Hanno
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages findutils depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
-- no debconf information
--- /usr/bin/updatedb 2005-03-20 10:48:27.000000000 +0100
+++ updatedb 2005-07-26 11:05:56.000000000 +0200
@@ -143,7 +143,12 @@
# To avoid breaking locate while this script is running, put the
# results in a temp file, then rename it atomically.
-if test -s $LOCATE_DB.n; then
+
+### don't test -s! $LOCATE_DB.n _will_ have a non zero size, even if
+### one of the commands in the pipeline fails
+### (see also debian bug #90381)
+# hmm, this will probably break, if frcode changes it's output on zero input
+if [ `stat -c '%s' $LOCATE_DB.n` -gt 10 ]; then
rm -f $LOCATE_DB
mv $LOCATE_DB.n $LOCATE_DB
chmod 644 $LOCATE_DB
@@ -205,7 +210,8 @@
# To reduce the chances of breaking locate while this script is running,
# put the results in a temp file, then rename it atomically.
-if test -s $LOCATE_DB.n; then
+if [ `stat -c '%s' $LOCATE_DB.n` -gt 10 ]; then ### see above why not test -s
+# if test -s $LOCATE_DB.n; then
rm -f $LOCATE_DB
mv $LOCATE_DB.n $LOCATE_DB
chmod 644 $LOCATE_DB
