Date: Sun, 3 Sep 2000 21:11:43 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: FreeBSD-gnats-submit@freebsd.org Subject: bin/21017: mtree's "no such file" message at job's end Message-ID: <20000903211143.T252@speedy.gsinet>
next in thread | raw e-mail | index | archive | help
>Number: 21017
>Category: bin
>Synopsis: mtree "no such file" message at job's end
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Sep 03 12:20:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator: Gerhard Sittig
>Release: FreeBSD 4.1-STABLE i386
>Organization:
in private
>Environment:
I've seen this on two FreeBSD 4-STABLE systems built in July and
on one FreeBSD 4-STABLE system built in August.
>Description:
mtree -c -K $KEYS | mtree -K $KEYS
produces an (IMO) erroneous "no such file" error message for
large mtree -c output with a line number one bigger than the
database size and a filename which "isn't real".
>How-To-Repeat:
I built a "tripwire lookalike" script using mtree. The database
is generated with the following command:
MTREE=/usr/sbin/mtree
KEYLIST=nlink,type,mode,flags,uid,gid,size,time,cksum,md5digest,sha1digest,ripemd160digest
for FS in / /tmp /var /usr /home; do
DB=$DBDIR/`echo $FS | tr '/' '_'`
EX=`[ -r $DB.ex ] && echo -X $DB.ex`
$MTREE -c -K $KEYLIST -p $FS -x $EX > $DB.db
done
Checking the fs' content against the database is done via
...
$MTREE -K $KEYLIST -p $FS -x $EX < $DB.db
...
The checking command's output at the /usr fs is:
mtree: line 395022: libtermcap_p.a: No such file or directory
"wc _usr.db" output:
395021 929838 21246776 _usr.db
"cat _usr.ex" output:
./obj/*
This behaviour is repeatable here, works for "small" filesystems
and fails at /usr. The other machines list "30_qmail.sh" (an
/usr/local/etc/rc.d start script) and "X11" as the "missing" file
which makes me say "the filename isn't really searched for or
shouldn't be". It's not the last and neither is it the longest
name in the list to be checked.
Some statistics:
stein "uname -a" output:
FreeBSD stein.gsinet 4.1-STABLE FreeBSD 4.1-STABLE #0: Mon Jul 31 19:17:22 CEST 2000 root@stein.gsinet:/usr/obj/usr/src/sys/STEIN i386
stein "wc *" output (/usr fails, see above):
3455 10684 203428 _.db
395021 929838 21246776 _usr.db
1 1 8 _usr.ex
756 1741 35231 _var.db
organ "uname -a" output:
FreeBSD organ.gsinet 4.1-STABLE FreeBSD 4.1-STABLE #0: Tue Aug 29 01:32:17 CEST 2000 root@organ.gsinet:/usr/obj/usr/src/sys/ORGAN i386
organ "wc *" output (/home works! /usr fails):
4328 12284 250597 _.db
505369 1182903 26115651 _home.db
601 1421 36233 _mnt_DOS.db
32 75 670 _tmp.db
1361948 3202398 74490769 _usr.db
1 1 8 _usr.ex
4288 9492 197807 _var.db
The third machine is further away and not accessible right now.
The error looks quite random and seems to occur when huge data
amounts sum up (rare / strange program paths are passed? buffers
get overridden?). It's not about fix values, compare stein's
/usr against organ's /home (organ has more processing power and
way more RAM and this seems to matter).
I don't know what's going on when encountering EOF of the
database stream and what conditions have to meet to trigger this
failure message.
>Fix:
None known yet, I couldn't even find the problem spot. But you
can ask me to watch out for whatever you like -- the error is
absolutely reproducable here.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000903211143.T252>