Attempting to view an archived site raises tar error "option -a is not permitted in mode -x"

[kendocode]

First, I'd like to echo the thanks for making this package. I have tried and failed several times to cobble something similar together on my own.

I'm not sure if this is meant to support MacOS, but I'm getting the above failure on Sonoma. I believe the cause is these lines:

                       ;; Assume that if it's not a zip file, it's a tar archive
                       ;; (`extension' will be just, e.g. "xz").
                       (_ (call-process (executable-find "tar") nil t nil
                                        "--auto-compress"
                                        "--extract"
                                        "--directory" temp-dir
                                        "--file" archive-path))))

When I cd into the attachments directory and run tar with those flags I receive the same error. If I omit the "--auto-compress" flag then I am able to successfully extract the archive.

I'm not sure how to fix this as I don't see a defcustom for extraction arguments as there are for archiving arguments. I don't even understand what compression means in the context of extracting an already compressed archive.

Would you consider this a bug that you might fix? If not, could you suggest a workaround?

[alphapapa]

Hi Ken,

Thanks for the kind words. I'm glad it's useful to you.

Indeed, I've never tried it on Mac before, but I'd be very surprised if you were the first to do so. My first suggestion would be, if you haven't already, to try installing GNU tar with Homebrew or something like that. That will probably fix it. If not, sure, we can add a defcustom for the arguments. (AFAIR --auto-compress just tells tar to determine the compression type automatically from the file extension.)

Thanks.

[kendocode]

Ah, --auto-compress now makes sense to me even for extraction.

Thanks for your suggestion to try installing gnu-tar. I hadn't realized it wasn't in coreutils. Unfortunately, I did that, and still have the issue. The problem is entirely with the Mac, which I have to use for work, and not with your package (which works great on my Linux machines).

A defcustom for the arguments, or for the tar binary path (since I do have GNU tar available, I just can't seem to figure out how to use it in preference to the BSD flavor) would certainly help me, but if I'm the only one having the issue I could try to fork and add it myself.

For anyone in future with this problem, (or better yet a solution), here is what I have tried.

1. brew install gnu-tar to ensure that is available
2. ensure that /opt/homebrew/opt/gnu-tar/libexec/gnubin is in the PATH, which allegedly allows GNU tar to be called with tar vs gtar

Results:

1. tar --version still reports bsdtar 3.7.2 - libarchive 3.7.2 zlib/1.2.11 liblzma/5.4.4 bz2lib/1.0.8 liblz4/1.9.4 libzstd/1.5.5
2. gtar --version reports

   Copyright (C) 2023 Free Software Foundation, Inc.
   License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
   This is free software: you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.
   Written by John Gilmore and Jay Fenlason.

I've read of similar sporadic issues, e.g. https://github.com/d12frosted/homebrew-emacs-plus/issues/466 that as far as I can see were not ever completely figured out.

[alphapapa]

Thanks for the detailed report.

Here's what I'd check next:

1. Ensure that the gnubin directory contains a tar executable.
2. Ensure that Emacs sees the gnubin directory in PATH (check with (getenv "PATH")). You may need to adjust where you set PATH to ensure that it's picked up by Emacs however you launch it (and you might need to log out/in again, depending on where you set it).
3. Ensure that the gnubin directory is at the front of PATH, before any other directories that might interfere.

AFAIK if those conditions are met, Emacs should find the GNU-provided tar executable first. You can also test by evaluating (executable-find "tar").

[kendocode]

Thanks for the suggestions. I finally got it working. It turns out this piece is easier said than done on a Mac.

Ensure that the gnubin directory is at the front of PATH

Macs have a "path helper" that runs after ~/.zshenv and sets system libs and some crypto stuff first. Also, Homebrew helpfully injects an eval() into ~/.zprofile that causes a reordering of the path to ensure its stuff is found.

tldr: I ended up moving my path settings into ~/.zshrc, and I basically do this (probably overkill but I find a couple more odd quirks have gone away):

typeset -U path
# PREpend the gnu utils paths
for bindir in "$(brew --prefix)/opt/"*"/libexec/gnubin"; do path=($bindir ${path[@]}); done
# APPend the other homebrew bins
for bindir in "$(brew --prefix)/opt/"*"/bin"; do path+=($bindir); done
# prepend the gnu man pages (optional)
for mandir in "$(brew --prefix)/opt/"*"/libexec/gnuman"; do manpath=($mandir ${manpath[@]}); done
# append the other homebrew man pages (optional)
for mandir in "$(brew --prefix)/opt/"*"/share/man/man1"; do manpath+=($mandir); done
export PATH path

If anyone wants to follow down the rabbit hole, I found these resources most useful: for finding the relevant brew paths for understanding the dreaded "path helper" I also looked at this tool which is supposed to automagically handle everything, but didn't test it out because I'd already got things working to my satisfaction. I might revisit it again in future.

Thanks again Alphapapa for the tool and for the helpful responses. Looks like I won't need that defcustom afterall.

[alphapapa]

@kendocode Great, thanks for documenting that process here!