From owner-freebsd-questions@FreeBSD.ORG Mon Jan 14 14:35:18 2013 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4903C92D for ; Mon, 14 Jan 2013 14:35:18 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 30ABDB9D for ; Mon, 14 Jan 2013 14:35:17 +0000 (UTC) Received: from [10.0.10.3] ([173.88.197.103]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jan 2013 06:35:16 -0800 Message-ID: <50F41797.2050001@a1poweruser.com> Date: Mon, 14 Jan 2013 09:35:03 -0500 From: Fbsd8 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lowell Gilbert Subject: Re: sh script problem with capturing return code References: <50EC9009.3030305@a1poweruser.com> <20130108224626.8c2d89cd.freebsd@edvax.de> <50EC99F2.3020404@a1poweruser.com> <44d2xevlhb.fsf@lowell-desk.lan> <50ED88CF.7060308@a1poweruser.com> <448v82unxb.fsf@lowell-desk.lan> <444niqum7n.fsf@lowell-desk.lan> <44zk0it6t5.fsf@lowell-desk.lan> <44r4ltu8zp.fsf@lowell-desk.lan> <50EE2604.4020809@a1poweruser.com> <44pq188tnx.fsf@lowell-desk.lan> In-Reply-To: <44pq188tnx.fsf@lowell-desk.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jan 2013 14:35:17.0120 (UTC) FILETIME=[5F2F5000:01CDF264] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: FreeBSD questions X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 14:35:18 -0000 Lowell Gilbert wrote: > Fbsd8 writes: > >> Lowell Gilbert wrote: >>> Lowell Gilbert writes: >>> >>>> I think it's a real bug, and the test cases don't cover "extra" elements >>>> at all. Now I just have to figure out the right fix. >>> I'm pretty sure that the fix is just to set rval on jumping to the >>> "extra" tag in vwalk() in src/usr.sbin/mtree/verify.c. >>> >>> But my hot water heater just exploded, so I may not look at code for a >>> few more days. >> Hello Lowell, >> Thank you very much. >> I was going crazy trying different combinations of options and script >> logic. I want to thank you for taking my problem seriously and taking >> the time to do your own test cases to verify my findings. Now that I >> know it's a genuine bug in mtree, I can make my plans accordingly. Any >> fix to the mtree utility will take some time to filter down to a >> regular RELEASE. Maybe 9.2 or the big jump to 10.0 by the end of >> 2013. I will leave it up to you the file a PR on this and follow >> through. >> Thanks again, people like you are what makes this questions list so >> valuable and FreeBSD such a great OS. You did outstanding work. > > Actually, in retrospect I think it was pretty trivial. I think the > following patch is the right fix for the problem, although I am not > completely certain. > > ================================================================ > Index: /usr/src/usr.sbin/mtree/verify.c > =================================================================== > --- /usr/src/usr.sbin/mtree/verify.c (revision 245177) > +++ /usr/src/usr.sbin/mtree/verify.c (working copy) > @@ -149,6 +149,7 @@ > } > (void)fts_set(t, p, FTS_SKIP); > } > + rval = MISMATCHEXIT; > (void)fts_close(t); > if (sflag) > warnx("%s checksum: %lu", fullpath, (unsigned long)crc_total); > ================================================================ > > This fixes the problem that was bothering you, but the interactions of > different features are complicated, and many of them are documented in > fairly loose language. > Is that the diplomatic way of saying the manpage for mtree sucks, and leaves a great deal to be desired? > > Would you be interested in extending the test suite for this program? > There are some tests in /usr/src/usr.sbin/mtree/test/, but they don't > cover your issue. I'm particularly concerned with interactions between > mtree(8) options like -u, -U, -q, -d, and specification keywords like > "optional", "nochange", and "ignore". I would feel more comfortable if > someone else wrote up new test cases (because programmers generally > don't -- can't -- test their own blind spots), although I'll certainly > do it if no one else does. > > I haven't submitted a PR yet, but I'll do so as soon as I've translated > my test case into a form that can be used in the PR. > > > Lowell here is my situation, I support a port and needed a method to interrogate the content of a small directory tree for correctness before processing it's content. I first developed a coding logic using mtree for this purpose, but that brought to light this mtree bug which is the subject of this post. Since my port only uses utilities that are contained in the base system of a RELEASE I could not very well wait for any patches to mtree to filter down into a RELEASE before updating my port. So instead I developed a coding logic using diff that does the same thing I was doing with mtree but diff issues the correct return codes. I have since updated my port in the ports system. When it comes to testing your patch sure I would like to. But here again I have a problem. For security reasons I can not use source code to install or update any operating system. I have no sources on my system to compile from. I use the fresh install method from a downloaded disc1.iso burned to cdrom. This way I know beyond a shadow of a doubt I have an un-compromised, clean, virgin system to start with and nothing present or left over from previous running systems that can be used to compromise the system. Now if you would use gzip to compress the binary patched version of mtree you have been testing with and email it directly to me offline of this list, then sure I will test it inside a jail and even play around with the other option flags your interested in and provide you feed back off list. Joe