Unzip bug in Ventura 13.1 on MacBook Pro 14 M1 Pro

On a Mac, probably for historical reasons, the default application assigned to a .bin file is the Archive utility, which also uncompresses (as well as archives, or compresses) files. Your original posting shows this in the image, the "type" is a Macbinary Archive for that file.

This is intended in the MacOS, it is not a bug. You can test this by creating a file and give it a .bin extension. Immediately the MacOS assigns it to be the Macbinary Archive file type. Do a Get Info and you will see this. The .bin file extension has been used in the past to designate Macbinary archives, that is the reason.

The .bin extension is also used for other things, in this case your firmware update. There is no harm done because decompressing such a file simply does not work, it is not an archive but a firmware file. So the MacOS tries but immediately stops, with that message you saw. The .bin file is still there untouched for you to use. (And even if somehow it was able to be decompressed, the original .bin file would be untouched.)

So no harm is done, your .bin file is there for you to use.

Whether you call this a "bug" or a "feature" is up to you. There are some Mac files that are .bin files and are indeed archives that the Mac can uncompress if or when needed. The MacOS can't tell the difference when .bin is used for multiple things. You can search on your Mac for all files that contain .bin in their name and you will see that all are assigned to be Macbinary Archive in file type. The MacOS can't tell the difference between the Macbinary Archive files and files that use .bin but are actually other types (not archives).

I would ignore this harmless error message because it simply comes about from the use of .bin for different things and has no impact on your Mac operation nor in the availability of that .bin file.

P.S. I too have accidentally replied to the wrong person is these Discussions, no harm from that either! I too sometimes struggle with a small laptop screen!

When a file extension, like .zip is associated with a Native Application, like the Uncompress application, things this are bound to occur.

The user may consider using the Command i - Get Information.

Then reassign the .zip extension to the Desired Their Party Application

Further to guard against the Auto Launch of Uncompress

Disable the feature in Safari to Auto Open Safe Files

images ( 2 below )

Kurt Friis wrote:

We agree, that there was no harm done. In THIS specific case.

The problem is: Will that always be the case, for all zip files ending up in our machinery?

IF Apple still uses this approach, without even checking, if it makes sense before unzipping, I may not even be warned about the "less than optimal handling" of content, ending up in decoded, maybe executable form (depending on sort settings, I may not even notice the "odd addition" to the original unzip operation

This sounds a little over dramatic to me. You are certainly entitled to your opinion about these things.

Zip files are handled properly on Macs, they are unzipped.

But when it produces a .bin file that resulted from unzipping a zip file, the Mac may try to decompress that as well because it is an extension used in the past for archives. That decompression stops immediately (as happened in your case) when in fact it is a binary file, not an archive. The MacOS does not try to execute the .bin file, it just checks to see if in fact it is an archive that can be further decompressed.

This in fact is the behavior I would want to see.

Note that decompression and unzipping always leaves the original file untouched. So if the output is gibberish, the original is still preserved as it was. But the MacOS is smart enough to recognize that some .bin files are in fact not archives so it stops.

I don't see any risk from this. You use terms like "dangerous" and "authorized personnel" ... not sure why, we are talking about people using their Macs, a file with an extension (.bin) that can mean multiple things, and the Mac handled it correctly. No third party unwanted code executes ... a built in Mac decompression program checks a file and determines it is in fact not an archive and thus does nothing, and informs you.

Zip files are considered a potential security risk on PCs because they could be uncompressed into an executable and then executed, and that execution could result in software running that does harm. On the Mac, before anything is run or executed, the Mac asks "this is an application downloaded, are you sure you want to run it." You have to affirmatively answer yes and click a button. The user can always choose to do things that can damage files. However, the Mac protects against that, as described above. And since the MacOS is now stored in a sealed read-only volume, it cannot be corrupted by anything like this.

If you can point out an aspect of this unzip and .bin situation that poses a risk to any Mac users, please explain the SPECIFIC basis of your concern.

Give this a try: boot into Safe Mode according to How to use safe mode on your Mac and test to see if the problem persists. Reboot normally and test again.

NOTE 1: Safe Mode boot can take up to 3 - 5 minutes as it's doing the following; 

• Verifies your startup disk and attempts to repair directory issues, if needed

• Loads only required kernel extensions (prevents 3rd party kernel/extensions from loading)

• Prevents Startup Items and Login Items from opening automatically

• Disables user-installed fonts 

• Deletes font caches, kernel cache, and other system cache files

NOTE 2: if you have a wireless keyboard with rechargeable batteries connect it with its charging cable before booting into Safe Mode. This makes it act as a wired keyboard as will insure a successful boot into Safe Mode.

According to your statement, “Pages.app.bin” should not be unzipped.

You confused yourself. Pages.app.bin isn't a binary file, it is a zip compress application bundle.

When the unarchiver attempts to decompress the binary archive, it finds a zip archive which it can uncompress, also.

If it wasn't really a zip archive, it would not have been decompressed.

Changing the file extension doesn't change the internal structure.

Kurt Friis wrote:

Don’t you agree? 

No, I don't agree. Barney explained it, but I expect you will continue to see this differently. The MacOS behaves predictably. Whether you consider this a "bug" or just "normal expected behavior," there is still no consequence.

Rather than endless back and forth in this forum, feel free to report what you think is a bug to Apple directly:

Bug Reporting - Apple Developer

Product Feedback - Apple

As someone who works on space flight systems, I can tell you how we approach prioritizing things to change in our software (or hardware): the items that have no negative consequences are the LAST ones we will address, if ever. Changing operational software in any way carries some risk of unintended consequences, so there is a general rule to not make changes unless there is a compelling reason to do so. I suspect Apple follows something similar. Any change to the MacOS requires extensive testing and validation, it all costs money, and making unnecessary changes is always avoided.

Let us know if Apple responds to your "bug" report.

Kurt Friis wrote:

In this case, the consequences were limited to executing an extra decompression, not requested by the user (and failing, as file content differed from content expected by the system. No check on actual content prior to execution was done).

No. There was no "extra decompression." The Apple software did check the file content BEFORE DOING ANYTHING and immediately reported that it was not the right format and did NOTHING. It did the right thing. My opinion differs from yours because in my view, this is harmless and it's the right behavior, it's what I would want.

See the links I provided for providing feedback to Apple.

Bug Reporting - Apple Developer

Product Feedback - Apple

(Rudegar also provided the feedback link)

Feel free to use a PC for zip files. PCs perform many more "automated actions" not directly under user control, and are much more vulnerable to malware or even viruses introduced many different ways, including zip files.

It is actually impossible to introduce a virus on a modern Mac because the system is in a sealed, read-only volume (actually a snapshot).

zip not sure when it was introduced native in macos but it did not used to nor did it in windows or dos

people used to use stuff like winZip and WinRar and WinAce to handle compressed files.

not sure why it malfunction for you, I usually use double commander for such things myself

you can provide them with feedback using their feedback channel

Feedback - macOS - Apple

Errors do occur

Perhaps the Technical suggestion was not to the liking of the Recipient

It does become difficult to determine who Whom the reply was instead as there are at least 3 Contributors involved on this question.

Best I do not take up any more of the Users time.

Best of luck with this computer issue

Kurt Friis wrote:

The unzip of the bin file stops immediately with an error message.

This indicates, that there was no check, if the file should have been unzip'ed in the first place.

If a file is successfully unzip'ed, but not "authorized", what will happen?

(1) 'Cannot decompress "S5___V26.bin". The format is not supported.'

Obviously it did check and noticed an unsupported format and thus did nothing.

(2) Since it did nothing, there is nothing to fear.

(3) You can't "unzip" (I assume you mean "decompress" because a .bin file is not a zipped file) a file that not in the proper format. So even if it had tried, the result would have been gibberish.

I still don't see how any of this is a concern. This is like trying to open an Excel file with Preview. It simply doesn't work, nothing happens, it's not a concern.