Lowell Gilbert wrote:
Fbsd8 <fb...@a1poweruser.com> writes:
Lowell Gilbert wrote:
Lowell Gilbert <freebsd-questions-lo...@be-well.ilk.org> 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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
