Failed to activate: Cannot restore xattr:com.apple.decmpfs

[chucko58 (Chuck Fry)]

I did a routine 'port selfupdate' from MacPorts 2.4.2 on macOS 10.12.6, which succeeded and resulted in MacPorts base getting updated to 2.5.0.

I then tried to do a routine 'port upgrade outdated', which failed with an error activating libidn2 v2.0.5.

'port rev-upgrade' encountered 4 broken files and 3 broken ports, but again failed trying to activate libidn2.

See the attached log file. Note that MacPorts is installed without root privileges on this system.

[chucko58 (Chuck Fry)]

MacPorts log from attempt to update libidn2

[ryandesign (Ryan Carsten Schmidt)]

The only other reference to Cannot restore xattr:com.apple.decmpfs I can find is comment:ticket:36560:26 in which the HFS compression code for MacPorts was implemented.

Does this problem only affect libidn2 or also other ports?

[chucko58 (Chuck Fry)]

It does not seem to affect any other ports. But because libidn2 is a dependency for several other ports, including libpsl, gcc7, and curl, I cannot update them until this is resolved.

I did search for that string, both here and on the web generally, and didn't find any useful information about how to recover.

[chucko58 (Chuck Fry)]

Failed to mention: libidn2 was the first port updated by 'port upgrade outdated'.

[jmroot (Joshua Root)]

A workaround should be to set hfscompression no in macports.conf.

[chucko58 (Chuck Fry)]

Thank you, the workaround resolves my problem.

[ryandesign (Ryan Carsten Schmidt)]

But why did hfscompression yes cause this problem, and how do we fix it so that it doesn't?

[ryandesign (Ryan Carsten Schmidt)]

Duplicate #56566 shows the problem occurring with git.

[raimue (Rainer Müller)]

This error seems to indicate that ​fsetxattr failed on the file in question.

I cannot reproduce the problem with libidn2 @2.0.5_0 on my macOS 10.12.6 installation. I am using the archive produced on the buildbot. Do you have the same archive file?

$ openssl dgst -sha256 $(port -q location libidn2 @2.0.5_0)
SHA256(/opt/local/var/macports/software/libidn2/libidn2-2.0.5_0.darwin_16.x86_64.tbz2)= 9130668f927970dcc7620f71ccb43d3e593751fe158bb71075801f9aef463736

[raimue (Rainer Müller)]

Oh, wait, I was not looking closely and only noticed now that you are installing into a custom prefix in your $HOME. What kind of filesystem are you using? Is there anything else special about your setup? What kind of filesystem are you using?

[chucko58 (Chuck Fry)]

Standard HFS+ root file system on an Apple SSD. MacPorts is installed without root privileges because I'm on a government owned computer and they won't let me administer it. I'll attach a system report.

[chucko58 (Chuck Fry)]

System Information report

[eborisch (Eric A. Borisch)]

Is your libarchive out of date? (Unlikely unless you haven't upgraded in quite a while, but thought I would ask.) What does which bsdtar report?

[eborisch (Eric A. Borisch)]

I can reproduce this if I'm not root when running the extraction. Looks like something to report upstream; I will do that later today when I have time.

[chucko58 (Chuck Fry)]

rdnzl:~ cfry$ which bsdtar
/Users/cfry/bin/bsdtar
rdnzl:~ cfry$ 

[chucko58 (Chuck Fry)]

rdnzl:~ cfry$ ls -l /usr/lib/libarchive*
-rwxr-xr-x  1 root  wheel  448368 Mar  7 22:36 /usr/lib/libarchive.2.dylib
lrwxr-xr-x  1 root  wheel      18 May  1  2017 /usr/lib/libarchive.dylib -> libarchive.2.dylib
rdnzl:~ cfry$

[chucko58 (Chuck Fry)]

rdnzl:~ cfry$ ls -l ~/lib/libarchive*
-rwxr-xr-x  1 cfry  513   638972 Mar  5 17:55 /Users/cfry/lib/libarchive.13.dylib
-rw-r--r--  1 cfry  513  1007936 Mar  5 17:55 /Users/cfry/lib/libarchive.a
lrwxr-xr-x  1 cfry  513       19 Mar  5 17:55 /Users/cfry/lib/libarchive.dylib -> libarchive.13.dylib
rdnzl:~ cfry$ 

[chucko58 (Chuck Fry)]

rdnzl:~ cfry$ bsdtar --version
bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.2.3 bz2lib/1.0.6 liblz4/1.8.1
rdnzl:~ cfry$ 

Sorry, I'm still on my first cup of coffee.

[eborisch (Eric A. Borisch)]

I’ve narrowed this down to writing out non-zero sized files that are read-only (0444, for example) when not the root user. I’ll file a bug with libarchive, but for now we should put a [geteuid] == 0 into the conditions checked to enable compression. I don’t know if this is a new 10.13 error (with fsetxattr on a file you own but marked read-only) or if it’s been around.

On the positive side, it properly warned that it had encountered an error. ;)

[chucko58 (Chuck Fry)]

As I first encountered it on macOS 10.12.6, it's unlikely to be new to 10.13.

[eborisch (Eric A. Borisch)]

The underlying cause (normal user attempt to modify extended attributes fails for an owned but read-only file) has existed for some time in libarchive: ​https://github.com/libarchive/libarchive/issues/497 and is fairly cross-platform.

Based on that, we definitely want to roll out a check of euid sooner than later and disable compression if != 0.

[eborisch (Eric A. Borisch)]

I've submitted a PR with a fix that "works for me": ​https://github.com/libarchive/libarchive/pull/1023 but it certainly needs review from the maintainers of the software.

[jmroot (Joshua Root)]

In cf91a8b9c653cde19dc5adce1ffab327fb9fac53/macports-base (master):

Disable hfscompression for non-root installs

Due to a bug in bsdtar, xattrs fail to be restored for read-only files.
Being root naturally circumvents this problem.

See: #56563

[jmroot (Joshua Root)]

In 7ba8b30e1fdaa42b680af1a5d3b09be15a1c730f/macports-base (release-2.5):

Disable hfscompression for non-root installs

Due to a bug in bsdtar, xattrs fail to be restored for read-only files.
Being root naturally circumvents this problem.

See: #56563
(cherry picked from commit cf91a8b9c653cde19dc5adce1ffab327fb9fac53)

[mf2k (Frank Schima)]

Has duplicate #56580.

[jmroot (Joshua Root)]

The fix is in libarchive 3.4.0, [c5b8cab0399660d99d62fd3926c7477174888aac/macports-ports].

[jmroot (Joshua Root)]

In 5346aa87bc4007714d182ea5de79693e72074385/macports-base (master):

Re-enable hfscompression for non-root installs

The bug that necessitated this was fixed in libarchive 3.4.0.

See: #56563

[jmroot (Joshua Root)]

If someone with a non-root installation could verify that it works that would be great.

[bheavner (Ben Heavner)]

I can verify that the fix worked for me. I set hfscompression no in macports.conf, then updated libarchive, then commented out the hfscompression no setting, and subsequent macports installs and updates worked.

[jmroot (Joshua Root)]

Thank you for the confirmation.

[sixcircuit (Kendrick Taylor)]

I just got a brand new laptop from apple with Catalina installed. Went to do a non-root installation of MacPorts. Compile and install worked fine but I ran into this bug in MacPorts 2.6.2. I had to set hfscompression no in macports.conf. I don't know if this is expected behavior or not. It seems like you think it's fixed. I just wanted to let you know, it wasn't for me. I'm glad this thread existed.

Thanks for great software. I've been using it for years.

[jmroot (Joshua Root)]

The bug was fixed in libarchive 3.4 as confirmed in comment:29. Are you saying you are seeing it with the current version of libarchive installed, or without the libarchive port installed at all?

[ryandesign (Ryan Carsten Schmidt)]

See #60230 which shows we still have a problem here...

[jmroot (Joshua Root)]

Replying to ryandesign:

See #60230 which shows we still have a problem here...

More accurately, libarchive 3.4.2 has a problem here again.