Re: [libarchive-discuss] mtree(8) keyword clarification: "device"

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Le 04/09/2013 05:44, Tim Kientzle a écrit :
> > Libarchive does it differently and log it as 
> > "device=native,<major>,<minor>" format.
>
> Libarchive's mtree support has evolved quite a bit in order to
> try to be more compatible with other implementations.  We're
> happy to get help in continuing to improve this.
>
> I believe the current code was heavily influenced by the FreeBSD
> implementation of mtree(8), which is a little different from NetBSD's
> implementation.

christos@ answered my question to this, and I pushed the code that does 
the format,major,minor parsing as well as "packing" (e.g. converting the 
format to the appropriate dev_t).

See https://github.com/libarchive/libarchive/pull/47

This would need a review though, I am familiar with NetBSD KNF, and not 
with libarchive's and its cmake :)

> Libarchive tries to be intelligent about handling variant formats.
> We would be happy to see patches that made this more
> flexible.

See above.

> It looks like it should be relatively simple to expand parse_device()
> in libarchive/archive_read_support_format_mtree.c to handle other
> formats.  I would suggest first checking for the number of comma
> characters.

That's what I did.

Another question then: I am willing to extend mtree(5) format so it can 
store st_rdev (the resident device ID) and the inode so that I can 
obtain a "unique" node ID based on the device number on which the node 
reside combined with its own inode.

"device" being already used, I went with "resdevice" (for "resident 
device") and "inode".

My initial patch was against NetBSD's mtree(5) [1]; I turned the binary 
into a library for a $DAYJOB project, but joerg@ then suggested using 
libarchive, which already has mtree(5) support in addition to being, 
well... a library, with tons of other archives/compression formats 
recognized.

Indeed, the advice was good, and I moved to working with libarchive, 
but as our team already use mtree(5) quite extensively, I would like to 
make a drop-in replacement and have an mtree(8) binary based on 
libarchive (like bsdtar and cpio).

That could also provide the same mtree for both NetBSD and FreeBSD 
(through libarchive), but this is more "pie in the sky" for now. There's 
still some code to write before I achieve that purpose. Does that fit 
libarchive's goals too?

Thanks!

--
Jean-Yves Migeon