tech-userlevel archive

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

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

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

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).


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

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

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?


Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index