Re: Handling APFS/HFS+

 ---- On Mon, 01 Jun 2020 12:07:37 -0700 Denis Corbin <[email protected]> wrote ----

[All good to here, in fact excellent regarding the list of attributes etc that `dar` can handle on Apple disks, so thank you.  I'll just snip that now.]

Unfortunately from here, I've still failed to be sufficiently clear.  I'll give it another go!

> > Could I extract the particular files that may be giving me trouble
 > >  when I try to restore them to the linux FS and save them to a 
 > > separate dar archive for later handling, without losing any data?
 > 
 > if you have cannot restore a file and want to keep as much information
 > of it in a separated archive, you should use the filtering feature (see
 > merging feature) that let you create an archive from a subset of a
 > bigger one. This is done without restoring the files/directories so you
 > do not depend on the operating system to support all data and meta-data
 > associated to that file(s).

Ok, so one of the things I can do with a dar archive containing HFS+ files, but which I am manipulating on linux, is restore the files that are not producing errors, but create a new, smaller, archive containing only the problematic files.

 > > How much control do I have over the contents of the archive *from
 > > linux*?
 > 
 > In short, you can define which file and directory to save, which EA and
 > FSA to take into account, which file to save the data to the archive or
 > just store as existing file (context: snapshot and differential backups).

Fine.

 > For a detailed answer, as you have found the documentation ;^) you
 > should easily get it.
 > 
 > >>> Also, if I were to then try to copy that archive to a linux 
 > >>> machine and explore it with `dar`, what would happen?
 > >> 
 > >> The Extended Attributes name has two parts, a name-space and a 
 > >> attribute name separated by a dot. For example "user.test" is an
 > >> EA name to which is associated an arbitrary long sequence of
 > >> bytes.
 > >> 
 > >> When restoring EA, dar asks the system to create such new EA to
 > >> the just restored file (or over an already existing file
 > >> depending on the context). The system may fail/refuse if the
 > >> support for the corresponding name-space is not present. Dar will
 > >> then report the failure to the user and continue with the next
 > >> file or fail depending on options set by the user, but dar will
 > >> try to restore the most possible things for a give file (data,
 > >> meta-data, EA and FSA(*)) before trying the next one.

Yes, this I've got.

But, can I look at the EA's that are not being extracted (failing), in order to see what they are?

What of a file that has a non-trivial resource fork?  Is there any way for me to look in that fork?  Can I extract it from the archive in some form and dig around in it?

Similar question for any other piece of data that is failing to restore.

 > > Not sure what FSA is?
 > 
 > FSA = Filesystem Specific Attributes.
 > 
 > for details see
 > https://en.wikipedia.org/wiki/Chattr
 > and
 > https://www.freebsd.org/cgi/man.cgi?query=chflags&sektion=1
 > 
 > Note that all lsattr/chattr attributes are taken into account this way,
 > this is not the case for the bsd chflags (these are the bsd flags
 > mentioned above about restic), but the current implementation can easily
 > be extended if needed, as mentioned previously.

I'll have a look, thanks.

 > > Yes, I appreciate your input.  Apple certainly hasn't made our
 > > lives easy, has it?
 > 
 > Well, I bet they did, by taking BSD as root of MacOS X, which advantaged
 > Unix-es systems (and Linux in particular) against Windows proprietary
 > systems. This simplified a lot of thing and put back openness in the
 > center of the game... See now, even Microsoft now likes Unix! :-)

I just installed Ubuntu and SUSE on my (rarely used) Windoze machine!!

/D