Opened 2 years ago

Closed 14 months ago

Last modified 6 months ago

#56563 closed defect (fixed)

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

Reported by: chucko58 (Chuck Fry) Owned by:
Priority: Normal Milestone: MacPorts 2.6.0
Component: base Version: 2.5.0
Keywords: Cc: eborisch (Eric A. Borisch), raimue (Rainer Müller), araven (Pascal Thibaudeau), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), vbogretsov (Vladimir Bogretsov), jmroot (Joshua Root)
Port:

Description

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.

Attachments (2)

main.log (31.9 KB) - added by chucko58 (Chuck Fry) 2 years ago.
MacPorts log from attempt to update libidn2
MacBook Pro.spx (4.6 MB) - added by chucko58 (Chuck Fry) 2 years ago.
System Information report

Change History (36)

Changed 2 years ago by chucko58 (Chuck Fry)

Attachment: main.log added

MacPorts log from attempt to update libidn2

comment:1 Changed 2 years ago by ryandesign (Ryan 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?

comment:2 Changed 2 years ago by 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.

comment:3 Changed 2 years ago by chucko58 (Chuck Fry)

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

comment:4 Changed 2 years ago by jmroot (Joshua Root)

Cc: eborisch raimue added
Component: portsbase

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

comment:5 Changed 2 years ago by chucko58 (Chuck Fry)

Thank you, the workaround resolves my problem.

comment:6 Changed 2 years ago by ryandesign (Ryan Schmidt)

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

comment:7 Changed 2 years ago by ryandesign (Ryan Schmidt)

Cc: araven added
Summary: 'port upgrade libidn2' fails; "Cannot restore xattr:com.apple.decmpfs" in logFailed to activate: Cannot restore xattr:com.apple.decmpfs

Duplicate #56566 shows the problem occurring with git.

comment:8 Changed 2 years ago by 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

comment:9 Changed 2 years ago by 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?

comment:10 Changed 2 years ago by 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.

Changed 2 years ago by chucko58 (Chuck Fry)

Attachment: MacBook Pro.spx added

System Information report

comment:11 Changed 2 years ago by 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?

comment:12 Changed 2 years ago by 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.

comment:13 Changed 2 years ago by chucko58 (Chuck Fry)

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

comment:14 Changed 2 years ago by 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$

comment:15 Changed 2 years ago by 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$ 

comment:16 Changed 2 years ago by 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.

comment:17 Changed 2 years ago by 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. ;)

comment:18 Changed 2 years ago by chucko58 (Chuck Fry)

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

comment:19 Changed 2 years ago by 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.

comment:20 Changed 2 years ago by 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.

comment:21 Changed 2 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: MarcusCalhoun-Lopez added

comment:22 Changed 2 years ago by 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

comment:23 Changed 2 years ago by 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)

comment:24 Changed 2 years ago by mf2k (Frank Schima)

Cc: vbogretsov added

Has duplicate #56580.

comment:25 Changed 14 months ago by jmroot (Joshua Root)

Milestone: MacPorts 2.6.0
Resolution: fixed
Status: newclosed

comment:26 Changed 14 months ago by 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

comment:27 Changed 14 months ago by jmroot (Joshua Root)

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

comment:28 Changed 14 months ago by jmroot (Joshua Root)

Cc: jmroot added

comment:29 Changed 12 months ago by bheavner (Ben Heavner)

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

Last edited 12 months ago by bheavner (Ben Heavner) (previous) (diff)

comment:30 Changed 12 months ago by jmroot (Joshua Root)

Thank you for the confirmation.

comment:31 Changed 11 months ago by 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.

comment:32 Changed 11 months ago by 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?

comment:33 Changed 7 months ago by ryandesign (Ryan Schmidt)

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

comment:34 in reply to:  33 Changed 6 months ago by 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.

Note: See TracTickets for help on using tickets.