#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)
Change History (36)
Changed 6 years ago by chucko58 (Chuck Fry)
comment:1 Changed 6 years ago by 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?
comment:2 Changed 6 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 6 years ago by chucko58 (Chuck Fry)
Failed to mention: libidn2 was the first port updated by 'port upgrade outdated'.
comment:4 Changed 6 years ago by jmroot (Joshua Root)
Cc: | eborisch raimue added |
---|---|
Component: | ports → base |
A workaround should be to set hfscompression no
in macports.conf.
comment:5 Changed 6 years ago by chucko58 (Chuck Fry)
Thank you, the workaround resolves my problem.
comment:6 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
But why did hfscompression yes
cause this problem, and how do we fix it so that it doesn't?
comment:7 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | araven added |
---|---|
Summary: | 'port upgrade libidn2' fails; "Cannot restore xattr:com.apple.decmpfs" in log → Failed to activate: Cannot restore xattr:com.apple.decmpfs |
Duplicate #56566 shows the problem occurring with git.
comment:8 Changed 6 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 6 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 6 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 6 years ago by chucko58 (Chuck Fry)
Attachment: | MacBook Pro.spx added |
---|
System Information report
comment:11 Changed 6 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 6 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 6 years ago by chucko58 (Chuck Fry)
rdnzl:~ cfry$ which bsdtar /Users/cfry/bin/bsdtar rdnzl:~ cfry$
comment:14 Changed 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Cc: | MarcusCalhoun-Lopez added |
---|
comment:22 Changed 6 years ago by jmroot (Joshua Root)
comment:23 Changed 6 years ago by jmroot (Joshua Root)
In 7ba8b30e1fdaa42b680af1a5d3b09be15a1c730f/macports-base (release-2.5):
comment:25 Changed 5 years ago by jmroot (Joshua Root)
Milestone: | → MacPorts 2.6.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
The fix is in libarchive 3.4.0, [c5b8cab0399660d99d62fd3926c7477174888aac/macports-ports].
comment:26 Changed 5 years ago by jmroot (Joshua Root)
comment:27 Changed 5 years ago by jmroot (Joshua Root)
If someone with a non-root installation could verify that it works that would be great.
comment:28 Changed 5 years ago by jmroot (Joshua Root)
Cc: | jmroot added |
---|
comment:29 Changed 5 years ago by 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.
comment:31 Changed 5 years 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 5 years 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 follow-up: 34 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
See #60230 which shows we still have a problem here...
comment:34 Changed 5 years 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.
MacPorts log from attempt to update libidn2