Date: Thu, 7 Sep 2000 12:20:03 -0700 (PDT) From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/21017: mtree's "no such file" message at job's end Message-ID: <200009071920.MAA92116@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/21017; it has been noted by GNATS.
From: Gerhard Sittig <Gerhard.Sittig@gmx.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Re: bin/21017: mtree's "no such file" message at job's end
Date: Thu, 7 Sep 2000 21:08:16 +0200
On Wed, Sep 06, 2000 at 22:26 +0200, Gerhard Sittig wrote:
>
> [ ... a whole bunch trying to chase it down ... ]
>
> To summarize: It's not about the broken symlink in itself.
> But readlink(2) fails at a broken symlink when something else
> happened before -- but I don't know what this is. :< Could
> bin/4961 (nonzero errno although there's no error) apply in
> this case?
I hate to disappoint the gentle reader here. :( Just when I
thought I had a grip to the problem -- it turned out to not lead
any further. Hmmm ...
I expanded /usr/src/usr.sbin/mtree/compare.c with the following
printout, did a make and made sure by means of strings(1) that I
ran the newly compiled executable:
----- snip ------------------------------------------------------
# cvs diff -u compare.c
Index: compare.c
===================================================================
RCS file: /home/ncvs/src/usr.sbin/mtree/compare.c,v
retrieving revision 1.15.2.1
diff -u -r1.15.2.1 compare.c
--- compare.c 2000/06/28 02:33:17 1.15.2.1
+++ compare.c 2000/09/06 20:07:23
@@ -362,6 +362,9 @@
static char lbuf[MAXPATHLEN];
register int len;
+ if (errno) {
+ warn("nonzero errno before readlink(2) in compare:rlink(%s)", name);
+ }
if ((len = readlink(name, lbuf, sizeof(lbuf) - 1)) == -1)
err(1, "line %d: %s", lineno, name);
lbuf[len] = '\0';
# strings /usr/obj/usr/src/usr.sbin/mtree/mtree | grep nonzero
nonzero errno before readlink(2) in compare:rlink(%s)
# truss /usr/obj/usr/src/usr.sbin/mtree/mtree \
-K $KEYS -p /usr -x -X $DB/_usr.ex < $DB/_usr.db \
2> ~/nonzero.err > ~/nonzero.std
# tail -15 ~/nonzero.err
read(0x3,0xbfbff520,0x400) = 1024 (0x400)
read(0x3,0xbfbff520,0x400) = 1024 (0x400)
read(0x3,0xbfbff520,0x400) = 168 (0xa8)
read(0x3,0xbfbff520,0x400) = 0 (0x0)
close(3) = 0 (0x0)
readlink("X11",0x804ef80,1023) ERR#2 'No such file or directory'
mtree: write(2,0xbfbff18c,7) = 7 (0x7)
line 1361949: X11write(2,0xbfbff1bc,17) = 17 (0x11)
: write(2,0xbfbff17c,2) = 2 (0x2)
No such file or directory
write(2,0xbfbff17c,26) = 26 (0x1a)
sigprocmask(0x1,0x280605a0,0xbfbff824) = 0 (0x0)
sigprocmask(0x3,0x280605b0,0x0) = 0 (0x0)
write(1,0xd2dd000,2466) = 2466 (0x9a2)
exit(0x1) process exit, rval = 256
----- snap ------------------------------------------------------
In the end I can only see two reasons for mtree's failure:
- readlink(2) barfs on broken symlinks under not known yet
conditions (after "long" runs?) and does so unpredictably
- mtree fails to chdir(2) to the new directory and therefor fails
to read _any_ file there with a relative pathname
The latter thought is new and comes from the fact, that "X11" on
organ as well as "30_qmail.sh" on the third machine are the first
files in their directories (and in the .db file's respective
section).
But this doesn't hold any longer when looking at "libtermcap_p.a"
on stein which is "in the middle" of the listing and the .db dir
section.
Once I can find another spare moment I will try to dump the
relevant info of the readlink invocation's environment (current
dir, fts' root + path + filename, fts' already provided slink and
access failure info, etc). And I will try to determine the
"needed" depth of the tree somewhere between /usr and
/usr/compat/linux/usr/lib to make the mtree run fail.
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.
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?200009071920.MAA92116>