I am using a 2022 Mac Studio M1 Ultra running Ventura 13.2.1, however I have been experiencing this issue since Monterey. I can't **compress** or **copy/duplicate** folders when the parent folder is synching to iCloud (i.e. there is a dotted-line cloud symbol to the right of the folder name in Finder), however *individual files* do not pose this problem and both functions work normally as soon as the parent folder is fully synched to iCloud. I have tried all the same things as this user brought up in a similar post here , however I have narrowed it down further to only be an issue when the folder is actively synching. This person seems to have solved the issue by reverting to a previous Time Machine backup, however I use Backblaze rather than Time Machine so this was not a workaround for me. **The Problems** ----------------- 1. When I try to zip a folder inside of a folder that is currently synching to iCloud I receive an error from Archive Utility that reads: "Couldn't communicate with a helper application." 2. When I try to duplicate or copy a folder to or from a currently synching iCloud folder I receive an error that reads "The Finder can’t complete the operation because some data in “” can’t be read or written. (Error code -36)"

Archive Utility vs BSD tar behaviour:

echo -n 'Hello' >hello.txt  # "Hello" in hello.txt
tar cvf hello.tar hello.txt # hello.tar contains "hello.txt" file with "hello" text
echo ' world!' >>hello.txt  # "Hello world!" in hello.txt
tar rf hello.tar hello.txt  # hello.tar contains 2 versions of "hello.txt" file a first with "Hello" text and second with "Hello world!\n" text
tar tvf hello.tar           # to confirm!
rm hello.txt                # hello.txt removal
tar xvf hello.tar           # tar extracts the two hello.txt files, i.e. the first then the second overwriting the first
cat hello.txt				# "Hello world!" expected

One-liner:

echo -n 'hello' >hello.txt; tar cvf hello.tar hello.txt; echo ' world!' >>hello.txt; tar rf hello.tar hello.txt; tar tvf hello.tar; rm hello.txt ; tar xvf hello.tar; cat hello.txt

Same behaviour with both BSD tar and GNU tar As "tar" stands for Tape ARchiver ... it is historically meaningful to provide the option to physically append a corrected file to the archive on recorded on the tape without requiring to completely erase the tape first ... Question: Now try to extract hello.tar with MacOS "Archive Utility" and you have only hello.txt with "Hello" ... why!? So to my point of view, "Archive Utility" does not extract all files ... -/- Bonus question: And if "hello.txt" already exists in the folder, "Archive Utility" will extract the first file as "hello 2.txt" without even requesting which action the user wants (i.e. a rename or an overwrite) ... why!?

I have a zip file, within it I have another zip file, and within that file I have a txt file. When I unzip the outermost file with Apple's archive utility, it unarchives the inner files automatically. Is there a way to prevent this from happening?

I want to copy my Google Drive folders to an external USB. Google prepares a zip file for me but if I extract that zip file, the & character in filenames are replaced with _. I don't want such a change. I tried the unzip in terminal window, The Unarchiver app and Mac's Archive Utility. Nothing creates the original filenames. Any suggestions? PS. I can't mirror sync Google Drive onto external disk directly unfortunately. I creates a hyperlink in the external drive and downloads everything onto a local folder. I don't have enough space to mirror the whole Drive. And there is no way to choose which folders to mirror. It is either nothing or all. How inconvenient everything is while my free 1 TB quota is running out.

I have a folder that contains many files, including some .zip, .tar, .tgz, 7z, and gz files. How can I test all archive files in this folder to verify if they are corrupted or not? The folder contains subfolders, which also contain archive files that I want to check. I use Mac OS X 10.10. On Microsoft Windows I use some file manager to list all archives: then use 7zip to test all archives at once:

I just experienced this issue described in this answer . I had downloaded a zip file containing a macOS app , and first unzipped it with Archive Utility, when trying to open the app, I got the error that it "could not be opened" (with no further clarification) just like in the Q&A linked to above. However, when I used Keka (third party archive software) to unzip, the app worked just fine. What is the technical explanation for this? Aren't zips and other archives supposed to come out literally the same, byte for byte? How can one unarchiver break the app, but not the other? I use Catalina on an Intel Mac.

In macOS 10.15.4, Archive Utility is able to open some gzipped ASCII text files but not others, depending on the contents of the text file. For example, this works: % echo "abc e" | gzip > ok.txt.gz; open ok.txt.gz But this fails: % echo "abcde" | gzip > bad.txt.gz; open bad.txt.gz The second example shows an error in Archive Utility: "Unable to expand 'bad.txt.gz' into 'folder'. (Error 79 - Inappropriate file type or format.)" I'm trying to figure out: 1. Is this a bug in Archive Utility, or am I somehow misusing the gzip format? 2. Assuming it's a bug, what *is* the bug? Which files are allowed and which aren't? Why I believe this is specific to Archive Utility on 10.15: - 10.14 and 10.13 don't seem to have this problem; the files open normally. - The bytes of the gzip files created on 10.15 seem to match ones created elsewhere, and open normally with gunzip on 10.15. Text file contents that work or don't work: - Text files without spaces don't work, such as "abcdefghijklmnopqrstuvwxyz" - Text files with spaces at the end don't work, such as "abcdefghijklmnopqrstuvwxyz " - Text files with internal spaces do work, such as "abcdefghijklmnopqrstuvwxy z" - Text files without spaces but shorter than five characters do work, such as "abcd" What could be going on?

After a little testing, I can't figure out what the difference is in the archive formats listed in the Preferences > Use archive format. Each time I compress a folder, each one has the same extension and file size. Can someone shed some light on this?

The title sums it up. For as long as I can remember if you open an archive, it expands into the current folder. Recently they all started going to my 'Downloads' folder. I figured there's a setting so I checked but it's set up correctly (see image). Thanks in advance! *2018 15in mbp, Catalina 10.15.3*

I downloaded Keka and the app works well, but when I created a test .iso file from some photos saved on an iPhone (a copy of the folder I placed on the Desktop), I noticed this unusual thing: The JPEG files all retained the modification date, but their creation date was set to 1 January 2001 00:00 When I created a DMG file, the JPEG files kept both the creation and modification dates. Why does this happen with file modification dates? I'd created the folder for cross-OS compatibility, since I was intending to send it as an email attachment (the folder was only around 12MB worth of files). Is this usual with archive utility type apps for the Mac when converting a folder to ISO?

I am creating .zip-files on windows that I want to make available to Mac-Users (created with ZipFile.CreatefromDirectory from .NET Core). However, when I extract these files on my Mac (running Mojave, using the context-menu's "Extract File"), it re-creates the source-folder that I had zipped - and a flattened structure in side that folder: where I previously had root\foo\bar.txt, I now have a file "foo\bar.txt" in the root-folder. How I can get a "foo" folder with "bar.txt"? Did that problem arise when I build the .zip or do I need to extract differently in order to preserve directory-structure?

As of macOS 10.14.6 (maybe since 10.14.0) I noticed that when I zip files directly within Finder (Select files, right click, compress) that the resulting Archive.zip contains the selected files but in another order than shown in Finder. Sort order in finder: alphabetically (by Name, ascending). Sort order in zip: i don't know what order it has... How can I set the sort order in ZIPs back to alphabetically? Screenshots: 1) This is the order in the Finder: 2) This is the order in the ZIP file when using macOS 10.14.6 compression (select all, right click, compress): So the order is 4 - 2 - 3 - 1 (instead of 1 - 2 - 3 - 4) 3) Here is the order in the ZIP file when using KeKa: I hope my question is clear now and we can avoid unnecessary "why is this important" comments... Thanks!

Last week I downloaded a zipfile from a website on my mac. When it finished downloading the file automatically opened (which it normally doesn’t; I would normally have to double click it first). This was already strange but I didn’t think too much of it. It asked me for a password, which I did not know. When I clicked “cancel” the archive utility just quit. After that, when I looked in my downloads folder the file was no longer there. So I looked in my trash folder to be shocked to see that the file wasn’t there either. So basically, the file was behaving very strangely and had just deleted itself. What does this mean? Is this just something archive utility can do? Or can it be that the file might have been malicious?

$ which xar /usr/bin/xar It's in /usr/bin. Does that mean it's preinstalled on mac?

Is there a way to automate creation of ZIPs containing files with common name elements? What I have are multiple variations of the same image: files/2250/**8199**print.jpg files/1200x1200/**8199**square.jpg files/1200x900/**8199**wide1.jpg files/1200x628/**8199**wide2.jpg files/480x360/**8199**small.jpg What I'd like to do is create some sort of application that goes into folders, finds related files (all contain "8199") and then archives them all into a new file named "cartoon8199.zip". I tried to create an Application via Automator, but couldn't figure out how to make the Name Contains field in Find Finder Items include a variable. Any ideas on how to achieve this? I'm on a Mac running HighSierra 10.13.3. Thanks in advance!

I really need help with this issue: whenever I try to open a word document file from my Mac, the archive utility application opens up and turns the .doc file into a .cpio file and if I click on that it then turns into a .zip file. I've tried to research and even called Mac Support and they were not helpful. I just want my MS Word files to open up when I double click on them. I don't know how to stop the archive utility from opening up. It's a repetitive cycle of .cpio file to .zip file to .cpio and so on. If anyone knows how to fix this issue please let me know.

I'm using OSX El Capitan (v10.11.2). The compression task was begun about 24 hours ago and had reached the About 5 seconds estimation after a couple hours. But it does not complete for whatever reason. What are the possible reasons for this issue?

I have a file sent to me as a file_name.tar.xzfile thats been compressed on ubuntu and I want to uncompress it on my mac. This isnt readily available out of the box so I looked up and installed a brew called gnu-tar. I know that I can uncompress it on the terminal but I would like to use this with the archive utility on my mac. Any ideas on how to achieve this?

When I unpack a zip archive (with standard 'archive utility') that was created under windows, cyrillic characters in filenames become some gibberish. Just the filenames are the problem, actual contents of files is ok. How to fix this? (Yosemite, if that's important. In general, I have a lot of files with cyrillic filenames — and they are displayed just fine (including on flash drives from windows users etc).) **Upd.** Looks like the source of the problem (many modern zip unarchivers assume that filenames are in unicode, but that's not always the case) and a possible **workaround** (convmv) is described e.g. at http://blogs.gnome.org/happyaron/2010/09/03/workaround-of-file-name-problem-while-unzip-handling-cjk-encodings/

Its a common problem that, when unzipping (read: 'open by double-click'), some .zip files result in a similar sized .cpgz file. But you expected an unzipped file or folder instead. The default unzip program in OS X is '/System/Library/CoreServices/Archive Utility.app' When you try to unzip it in the Terminal (/usr/bin/unzip) you see the following: $ unzip SE.zip Archive: SE.zip warning [SE.zip]: zipfile claims to be last disk of a multi-part archive; attempting to process anyway, assuming all parts have been concatenated together in order. Expect "errors" and warnings...true multi-part support doesn't exist yet (coming soon). error [SE.zip]: missing 8256083459 bytes in zipfile (attempting to process anyway) error [SE.zip]: attempt to seek before beginning of zipfile (please check that you have transferred or created the zipfile in the appropriate BINARY mode and that you have compiled UnZip properly) I have Mavericks 10.9.5 running, and a unzip -v learns us we are on version 5.52: $ unzip -v UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler. Send bug reports using http://www.info-zip.org/zip-bug.html ; see README for details. ... The funny thing is, the same 'corrupt' zip file extracts fine on my CentOS system. There is no error and the file seems fine. My CentOS system runs unzip version 6.00: $ unzip -v UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send bug reports using http://www.info-zip.org/zip-bug.html ; see README for details. ... My question: How can I update my version of unzip to version 6.00 or higher? And affiliated question: Will my new version of OS X unzip also have affect on the default unzip 'Archive Utility.app'? ps. *I prefer the use of a package manager like brew above compiling from source. brew install unzip results in: Error: No available formula for unzip*