[Bug 299336] mtree sometimes treats \052 (asterisk) in file names in verifications as a glob wildcard, likely [...] and ? notation too

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299336

            Bug ID: 299336
           Summary: mtree sometimes treats \052 (asterisk) in file names
                    in verifications as a glob wildcard, likely [...] and
                    ? notation too
           Product: Base System
           Version: 16.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: marklmi26-fbsd@yahoo.com

The examples used for this note are limited to use of \052 (for asterisk)
but likely other glob pattern notations have the same sort of issue.

The discovery context involved usage by poudriere(-devel)'s check_leftovers 
and check_fs_violation and getting false positives. This report is in terms 
of such a context.

The description is in terms of hacks to the poudriere(-devel) common.sh
script to avoid some specific failures from using a wrong file for 
comparison. bulk -t of science/psi4 gets a false negative in 
check_fs_violation when science/libint2-psi4 is checked. It involves file 
names like:

# pkg info -l libint2-psi4 | grep 6-31\*g | sort
        /usr/local/share/libint/2.8.1/basis/6-311g**.g94
        /usr/local/share/libint/2.8.1/basis/6-311gss.g94
        /usr/local/share/libint/2.8.1/basis/6-31g**.g94
        /usr/local/share/libint/2.8.1/basis/6-31g*.g94
        /usr/local/share/libint/2.8.1/basis/6-31g.g94
        /usr/local/share/libint/2.8.1/basis/6-31gs.g94
        /usr/local/share/libint/2.8.1/basis/6-31gss.g94

The mtree.* files end up with \052 notation instead of the asterisk literals
but they still end up being handled in places as asterisk global pattern 
matching characters that sometimes do not pick the right file for comparison, 
leading to mismatched sizes in the example context. There were also
complaints about some of those files being missing.

A tested investigatory hack to avoid the problem via use of the notation 
[\052] that would translate to a glob pattern for a literal asterisk was:

# diff -u /mnt/usr/local/share/poudriere/common.sh
/usr/local/share/poudriere/common.sh
--- /mnt/usr/local/share/poudriere/common.sh    2026-06-07 18:52:42.088132000
-0700
+++ /usr/local/share/poudriere/common.sh        2026-10-12 07:22:07.622065000
-0700
@@ -5171,8 +5171,9 @@
        local mnt="${1}"

        ( cd "${mnt:?}" && \
+sed 's/\\052/[\052]/g' .p/mtree.preinst "${MNT_DATADIR:?}/mtree.preinst}" | \
            mtree -X "${MASTER_DATADIR:?}/mtree.preinstexclude${PORTTESTING}" \
-           -f "${MNT_DATADIR:?}/mtree.preinst" -p . ) | \
+           -f - -p . ) | \
            while mapfile_read_loop_redir l; do
                local changed read_again

@@ -5251,8 +5252,9 @@
        tmpfile=$(mktemp -t check_fs_violation)
        msg_n "${status_msg}..."
        ( cd "${mnt:?}" && \
+sed 's/\\052/[\052]/g' .p/mtree.prebuild
"${MNT_DATADIR:?}/mtree.${mtree_target}" | \
                mtree -X
"${MASTER_DATADIR:?}/mtree.${mtree_target}exclude${PORTTESTING}" \
-               -f "${MNT_DATADIR:?}/mtree.${mtree_target}" \
+               -f - \
                -p . ) >> "${tmpfile:?}"
        echo " done"


With that the bulk -t no longer reported the false positives because the
correct files were used and psi4 was not rejected.

(No claim that the hack handles all possible file names with asterisk
character(s)
well. Imagine if the original file name had a [*] : it would end up with
[[\052]]
which would not specify a correct glob for the original sequence.)

See: 

https://github.com/freebsd/poudriere/issues/843#issuecomment-6102113392

and the following comment about some example ports and installation files with
file
names that include text that is also glob pattern text. (Just a quick attempt
at
finding some of the examples.)


Given the apparently long history of the mtree validation behavior, avoiding
Astonishment Issues might mean that a mode-control command line argument
addition
would be appropriate if anything is done about the behavior.

-- 
You are receiving this mail because:
You are the assignee for the bug.