[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
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
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) ; 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
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?
Main Index |
Thread Index |