tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Increasing FreeBSD compatibility in mtree

I've added more details on my requests for feedback at Alan's request.
I keep forgetting that most of the context I have on this is from
spending lots of time staring at the two versions.

Note that the output below includes a patch I just posted to the list
to add back newlines before each directory in the -n case to match
FreeBSD's implementation.

On Tue, Dec 11, 2012 at 02:21:52PM -0600, Brooks Davis wrote:
> On Tue, Dec 11, 2012 at 01:40:22PM -0600, Brooks Davis wrote:
> > Thanks to Christos for merging the majority of my changes.
> With these changes, there remain a few incompatibilities for which I'd like
> some feedback on possible resolutions.
> The -t option is the default on FreeBSD.  My initial approach was to add
> a -T option to turn it off and make -t the default on FreeBSD.  The
> advantage of this approach is that existing FreeBSD scripts wouldn't
> break and portable code could use -T or -t as appropriate.  I didn't get
> any feedback on this, but it wasn't committed so I'm not sure which
> direction to go.  Other options are to just turn -t on all the time
> without a way to disable it since this matches current FreeBSD behavior
> or to go with the existing behavior which would be consistent, but
> potentially confusing.  If I merge mtree to our stable branches I will
> have to go with something that changes the default to avoid breaking
> scripts there.

On FreeBSD the -u flag "updates owner, group, permissions, and
modification time of existing files to match the specification."  It
also updates the file flags.  On NetBSD all of that is true except
that modification times are not updated unless -t is specified and
the immutable and append flags aren't set without -i.  I think the
NetBSD default makes more sense, but I'm a little worried it may be too
disruptive on FreeBSD.  Certainly, if I merge NetBSD's mtree to a stable
branch I will need to make -u imply -t and -i and emit a warning.
Documentation may well be sufficient for 10-CURRENT.

> I'm considering make -c -i set jflag and print a warning.  The reason
> for this is that -i only makes sense with -c on FreeBSD and it looks
> like it's a no-op on NetBSD.  Does this make sense?  This might be best
> as a FreeBSD specific bit of compatibility code.

On FreeBSD the -i option is equivalent to the new -j option in NetBSD's
mtree in that it indents the output four spaces for each directory
level.  It's mostly useless in the face of -C (full path output) but
likely has users.

On FreeBSD -i only does anything when -c (print a specification) is
specified.  On NetBSD -i sets the schg or sappnd flags when a hierarchy
is being verified.  Thus it appears to be a no-opn with -c is given.
I'd like to propose making -c and -i imply -j with a warning as a
compatibility measure.  I'm thinking something like the following
untested diff though I could just do this on FreeBSD:

Index: mtree.c
RCS file: /cvsroot/src/usr.sbin/mtree/mtree.c,v
retrieving revision 1.43
diff -u -r1.43 mtree.c
--- mtree.c     12 Dec 2012 15:51:41 -0000      1.43
+++ mtree.c     14 Dec 2012 22:21:25 -0000
@@ -235,6 +235,11 @@
        if (lflag && uflag)
                mtree_err("-l and -u flags are mutually exclusive");
+       if (cflag && iflag && !jflag) {
+               jflag = 1;
+               warnx("-c and -i used together, assuming -j");
+       }
        if (cflag) {

> The remaining known issues are in output format.  Since changing output
> format is quite disruptive to users I'm leaning toward a -F option to
> enable FreeBSD compatible output.  Would such an option be acceptable or
> should I just use #ifdef __FreeBSD__ in our tree?  Obviously, if I merge
> the code I'd have to make that the default.  The differences I know of
> are:

In the following, consider the hierarchy under /tmp/a created with "mkdir
-p /tmp/a/b/c".

>  - A "..\n\n" is printed for the top level directory.

$ mtree -p /tmp/a -c -i -n

/set type=file uid=3006 gid=0 mode=0755 nlink=1 flags=none
.               type=dir nlink=3 size=512 time=1355518983.000000000

    b               type=dir nlink=3 size=512 time=1355518986.000000000

        c               type=dir nlink=2 size=512 time=1355518986.000000000




$ nmtree -p /tmp/a -c -j -n

/set type=file uid=1001 gid=0 mode=0755 nlink=1 flags=none
.               type=dir nlink=3 time=1355522292.000000000

    b               type=dir nlink=3 time=1355522292.000000000

        c               type=dir nlink=2 time=1355522292.000000000



The delta is the last two lines of the FreeBSD output aren't in the
NetBSD output.  I don't think this on is a big deal one way or another,
but I speculate that FreeBSD output may better support concatination.

>  - size keywords are printed for all file types.

As above FreeBSD emits size of all file types.  NetBSD only does so for
regular files.  

>  - -d mode suppresses most empty lines and uses type=dir in /set statements.

-d mode is directory only for both FreeBSD and NetBSD.  On FreeBSD is
suppresses blank lines so you can get output like:

$ mtree -p /tmp/a -c -i -n -d
/set type=dir uid=3006 gid=0 mode=0755 nlink=1 flags=none
.               nlink=3 size=512 time=1355518983.000000000
    b               nlink=3 size=512 time=1355518986.000000000
        c               nlink=2 size=512 time=1355518986.000000000

$ nmtree -p /tmp/a -c -j -n -d

/set type=file uid=1001 gid=0 mode=0755 nlink=1 flags=none
.               type=dir nlink=3 time=1355522292.000000000

    b               type=dir nlink=3 time=1355522292.000000000

        c               type=dir nlink=2 time=1355522292.000000000



NetBSD preserves the blank lines as in the samples above.  Additionally,
NetBSD unconditionally prints "type=file" in the /set statement which
means it is overridden on each line.  I believe the modifications to -d
in FreeBSD were intended to be used along with -i to make it easier to
maintain the historic /etc/mtree/BSD.*.mtree files.

I hope this makes what I'm looking for feedback on more clear.

-- Brooks

Attachment: pgpmkxjnTk3Jn.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index