bug-xorriso
[Top][All Lists]
Advanced

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

Re: mtree(8) specification files


From: Thomas Schmitt
Subject: Re: mtree(8) specification files
Date: Sat, 24 Sep 2022 19:38:47 +0200

Hi,

Ivan Shmakov wrote:
> The mtree(8) tool originates in BSD, but is also currently
> available in Debian (and, presumably, derivatives)

It's Debian state is feeble. It belongs to a package named "freebsd-glue"
which was removed from the release candidate "Testing" because of
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964661
More problems can be seen at
  https://tracker.debian.org/pkg/freebsd-glue

Actually "freebsd-glue" only installs a symbolic link mtree pointing to
/usr/bin/fmtree which is in "freebsd-buildutils". That package has similar
problems as "freebsd-glue":
  https://tracker.debian.org/pkg/freebsd-buildutils


> Nevertheless, the mtree(8) format has its shortcomings.
> In particular, it doesn’t record extended attributes, ACLs,
> or Ext2+ attributes

Currently i do not see much advantage over xorriso's recording of file
properties. The use of SHA256 is considered superior to xorriso's MD5
when it comes to detecting malicious manipulations. But for the mere
purpose of detecting storage damages, the 128 bits of MD5 give more
than enough redundancy.

Most of the mtree properties are already recorded in the Rock Ridge
information. The only info that might provide a significant benefit is
the timestamp with higher resolution.

The maximum recordable time granularity is 1/100 seconds (RRIP 1.12 "TF"
entry with LONG_FORM bit, ECMA-119 9.5.5 pointing to 8.4.26.1 with 17 bytes).
But restoring times currently is done by utime(2), which accepts only full
seconds as arguments.
The timestamp is inquired by iso_node_get_atime() and iso_node_get_mtime()
which deliver full seconds too.
libisofs records the TF entries without LONG_FORM, i.e. by the 7-bytes
format which only bears full seconds.


> With regards to xorriso(1), a feature to consider would be
> to read such a specification and apply it to the filesystem
> loaded

I think this would only make sense when restoring files from the ISO
to some other filesystem (i.e. in osirrox mode).


> Thoughts?

I think that before teaching the mtree format to other tools like xorriso,
one should invest the time into getting a portable implementation of the
mtree(8) program.

This project could also release reader code under BSD license which the
tool developers could easily add to their code.
(A call to validate the mtree file, a call to read a line into a struct,
... maybe more ...)


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]