[BUG] Keka failed to extract a specified zip file

[KLszTsu]

Configuration

• Keka version: 1.2.15 (4583)
• macOS version: 11.4 (20F71)

Describe the bug

Keka failed to extract a specified zip file. The link to the file is provided below.

To Reproduce

Steps to reproduce the behavior:

1. Go to this link, press the download link at the top of the page to download the zip file.
2. Extract the zip file with Keka and run it.

What has happened:

Finder says "SpyderXPro_5.8.pkg" is damaged and can't be opened. You should move it to the Bin.

log:

2021-06-29 17:20:59.454 Dev mode enabled
2021-06-29 17:20:59.455 Running on OS X/macOS version 11.4 (Build 20F71)
2021-06-29 17:20:59.455 Running sandboxed Keka (WEB) version 1.2.15 (4583)
2021-06-29 17:20:59.455 Used localization: en-GB
2021-06-29 17:20:59.519 DEV: Adding 1 files
2021-06-29 17:20:59.519 DEV: Waiting for more input: 0.250000
2021-06-29 17:20:59.520 DEV: Requesting access to all bookmarks
2021-06-29 17:20:59.520 DEV: Bookmarks updated: 3
2021-06-29 17:20:59.525 DEV: Ignoring bookmarked external path "/Volumes/fakepath" since it's not currently available (0)
2021-06-29 17:20:59.526 Bookmark is stale, removing it: /private/tmp/test
2021-06-29 17:20:59.526 DEV: Bookmarks updated: 2
2021-06-29 17:20:59.527 Can't start bookmark access: /private/tmp/test
2021-06-29 17:20:59.803 DEV: No bookmarked file access...
2021-06-29 17:21:00.301 DEV: Dismissing delayed tasks
2021-06-29 17:21:03.095 DEV: Bookmarks updated: 3
2021-06-29 17:21:03.097 DEV: Checking tasks queue
2021-06-29 17:21:03.127 DEV: Starting queued task
2021-06-29 17:21:03.128 DEV: Path set as unavailable: /private/tmp/IR24/SpyderXPro_5.8.pkg.kextraction
2021-06-29 17:21:03.131 DEV: OS: Version 11.4 (Build 20F71)
2021-06-29 17:21:03.131 DEV: Keka: v1.2.15-r4583 (WEB) (Sandboxed) (en-GB)
2021-06-29 17:21:03.131 DEV: Format detected: ZIP
2021-06-29 17:21:03.131 DEV: Binary used: kekaunar
2021-06-29 17:21:03.131 DEV: Arguments: (
    "-q",
    "-r",
    "-K",
    "-nq",
    "-o",
    "/private/tmp/IR24/SpyderXPro_5.8.pkg.kextraction/Operation",
    "/private/tmp/IR24/SpyderXPro_5.8.pkg.zip"
)
2021-06-29 17:21:03.630 DEV: Checking ended task
2021-06-29 17:21:03.631 DEV: Quarantine apply starting...
2021-06-29 17:21:03.645 DEV: {
    LSQuarantineAgentBundleIdentifier = "org.mozilla.firefox";
    LSQuarantineAgentName = Firefox;
    LSQuarantineDataURL = "https://d3d9ci7ypuovlo.cloudfront.net/spyderx/SpyderXPro_5.8.pkg.zip";
    LSQuarantineEventIdentifier = "AF91EF82-CABD-432F-8F37-55625039C5BB";
    LSQuarantineIsOwnedByCurrentUser = 1;
    LSQuarantineOriginURL = "https://support.datacolor.com/index.php?/Knowledgebase/Article/View/1835/159/spyderx-pro-58-macos";
    LSQuarantineTimeStamp = "2021-06-29 17:03:33 +0000";
    LSQuarantineType = LSQuarantineTypeWebDownload;
}
2021-06-29 17:21:03.647 DEV: Quarantine apply done
2021-06-29 17:21:03.647 DEV: Checking tasks queue
2021-06-29 17:21:03.651 DEV: Path set as unavailable: /private/tmp/IR24/SpyderXPro_5.8.pkg
2021-06-29 17:21:03.652 DEV: Path already set as unavailable: /private/tmp/IR24/SpyderXPro_5.8.pkg
2021-06-29 17:21:03.652 DEV: Path set as available: /private/tmp/IR24/SpyderXPro_5.8.pkg
2021-06-29 17:21:03.652 DEV: Path set as available: /private/tmp/IR24/SpyderXPro_5.8.pkg.kextraction
2021-06-29 17:21:03.653 DEV: (
    "OS: Version 11.4 (Build 20F71)",
    "Keka: v1.2.15-r4583 (WEB) (Sandboxed) (en-GB)",
    "Format detected: ZIP",
    "Binary used: kekaunar",
    "Arguments: (\n    \"-q\",\n    \"-r\",\n    \"-K\",\n    \"-nq\",\n    \"-o\",\n    \"/private/tmp/IR24/SpyderXPro_5.8.pkg.kextraction/Operation\",\n    \"/private/tmp/IR24/SpyderXPro_5.8.pkg.zip\"\n)"
)
2021-06-29 17:21:03.659 DEV: Stopping access to all bookmarks
2021-06-29 17:21:03.660 DEV: Ignoring bookmarked external path "/Volumes/fakepath" since it's not currently available

What should happen:

Keka should be able to extract this zip file correctly.

Additional Info

• I also try to use the unzip command (UnZip) to extract the file, which works perfectly fine and I'm able to open the SpyderXPro 5.8.pkg. An information is that unzip created the filename SpyderXPro 5.8.pkg instead of SpyderXPro_5.8.pkg
• Please note that this file contains a proprietary software developed by datacolor™, and by visiting the website, or downloading the software, you agree to be bound by datacolor's Terms of Use.

Yours faithfully.

[aonez]

Thanks for the feedback @KLszTsu! I can't reproduce the issue, is extracting properly in Big Sur 11.4, downloaded from Safari or Firefox. Even in /private/tmp/ path.

Could you try extracting the file to another destination, like the Desktop?

If still fails, please quit Keka, remove the preferences by executing rm -r ~/Library/Containers/com.aone.keka and try again.

Let me know how it goes :)

[KLszTsu]

Hi @aonez , after spending some time on the problem, I find the reason.

Unzip unzip the file directly to the working directory (pwd) without creating a folder to contain the file, but Keka will create a folder and put the extracted file inside.
So after Keka's extraction, we have something like this:

fakeuser@FakeComputer fakepath % ls -FR . 
SpyderXPro_5.8.pkg/	SpyderXPro_5.8.pkg.zip

./SpyderXPro_5.8.pkg:
SpyderXPro 5.8.pkg

As the folder Keka created to contain the extracted file has a .pkg extension, Mac recognize it to be a Package, so when I double clicked the extracted "Package" to run the installer, it failed. But instead I should get inside the folder and double click the real Package to install.

->

So in the end this is not Keka's fault :)
But this situation is really confusing for the user. I don't know if anything could be done, but you can close this issue if you want :D

->

Thank you for making this wonderful software!

Yours sincerely.

[KLszTsu]

I'm thinking about if really anything could be done, for example, don't create subfolder if the resulting filename for the subfolder is a Mac Package, even with the "Always extract in a subfolder" selected, or create subfolder without the Mac Package extension so that it won't be misinterpreted as a Mac Package.

Either way, this introduce an inconsistency in the design to say the least, and potentially many problem to arise later.

[aonez]

Thanks a lot for the extensive testing @KLszTsu! Indeed this should and can be fixed. I'm renaming the extension like this:

• Current behavior:file.pkg.7z results in intermediate folder file.pkg
• New behavior:file.pkg.7z results in intermediate folder file_pkg

This will be used for any extension (.wathever), because the number of bundle extensions (.app, .pkg, .kext...) is large and also third party extensions can be used, so that way the fix will be always working.

Here a test build: https://github.com/aonez/Keka/releases/download/dev-test-builds/Keka-1.2.16.r4589.7z

[KLszTsu]

Wow this is amazing! Thank you!

Although a small bug is that it seems to have some trouble handling archive name with space in it?
For example, Te st.app.7z.

[aonez]

Ups! Used URLWithString instead of fileURLWithPath 😅

Fixed build: https://github.com/aonez/Keka/releases/download/dev-test-builds/Keka-1.2.16.r4590.7z

[KLszTsu]

This is awesome!

Although I'm currently thinking about edge cases, and I did come into one right in my field.
I think it is not a rare case for someone to have a numbering system in the filename, like this:

And I definitely don't want it to extract into something like Prelude, Op.28, No_11.

But in the same time, it is also not rare for somebody to have something like this:

Because the .mp3 and .wav file is generated by .logicx. It is reasonable to include the .logicx extension in the archive.

So,...
Actually there are two wonderful solutions I can think of.

The first solution would be trying to find the same suffix inside the archive. If it is the case that the suffix is indeed an file extension, there would very possibly be a file or folder with the same extension in the archive.
This solution still has problems but it will work in most cases.

The second solution will be really trying to look up the suffix in the table and find if it is an extension. It doesn't have to be a bundle; Replacing file extension with underscore should always be understandable.
I'm not very familiar to Mac development but I find this really slow way to lookup file extension on a random StackOverflow post:

fakeuser@FakeComputer fakepath % /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks\
/LaunchServices.framework/Versions/A/Support/lsregister -dump |
grep "tags: *\.pkg"
tags:                       .pkg, .mpkg
tags:                       .pkg, 'pkg1'
tags:                       .pkg, .mpkg
tags:                       .pkg, 'pkg1'

This second solution should leave minimum problems.

Thank you :D

[aonez]

@KLszTsu sorry for the late response, two very bad weeks.

Note that this fix is only applied if the extraction contains a single folder with an extension. Let me know if with your tests with the prelude example this is affected.

[KLszTsu]

Thank you for the reply!
Don't worry. Take your time and deal with this thing anytime you like. Just don't merge the current commit into release branch by now.

I just checked the latest build you sent me before, and I think you may have remembered some small details wrong.
So don't be in a hurry. This is not a problem that requires immediate attention. I will wait for ya :)

Aforementioned "detail" if you really want to have a look:

The fix has nothing to do with the extraction happening in filename.7z.kextraction/Operation/ folder and nothing to do what is inside the original archive. What is related to the fix is the step that Keka moves the result out of filename.7z.kextraction/Operation/ folder and the fix is only applied when the preference "Always extract in a subfolder" is selected.

[KLszTsu]

Let me give you a quick recap when you have time back on this; I know the discussion above is pretty messy ;)

There is a settings in the Keka's preference that Keka will always extract archives into a subfolder.
Keka creates this subfolder using the filename of the original archive minus the archive's primary file extension.

A problem happens when the archive's filename contains a secondary file extension, and when the secondary file extension happens to be the extension of a bundle.
In this case, Apple Finder will misinterpret the subfolder Keka creates to contain the extracted file to be a bundle.

As fix is getting implemented in the build you sent me before, Keka now always replaces the dot before the secondary file extension with a dash, thus avoiding the subfolder Keka creates to have a file extension.
It works pretty well in the case it should have worked, but it happens to work as well when it shouldn't.

So I discussed a few potential ways to tell if it should do its work or not in this comment.
And this is where we left off.

[aonez]

I see your point about that "Prelude, Op.28, No.11.7z".

I've tested multiple solutions, one being that one you suggested (contents include the prefix). Also checking for the extension identifier (better than using lsregister). In this case, .11 is not a recognized type so would not be renamed but .app or .pkg will.

But those options still have some issues. For example compressing the Contents folder of an app and extract them in an intermediate folder named dummy.app will result in a working app, but renaming it to dummy_app will not. But this is a strange way of compressing an app and expect it to be properly extracted.

Finding a perfect solution is very difficult because there're so many cases, but for now I think I'll use the extension identifier check and will add a check in the preferences to enable/disable this feature.

[aonez]

This build has the feature implemented: Keka-1.2.16.r4608.7z

Let me know if you find any caveat.

[KLszTsu]

I think it looks pretty nice now. I like it :)

Some small sidenotes: I wonder if my English is awful (it is), but I don't think I can realize the "intermediate folder" below is the same thing as the "subfolder" above.
I don't know if there are better words to use, but other from that, maybe disabling the check box below when the check box above is not selected will help user understand the relations of the two check boxes.

---

Another thing I'm also thinking about is if using underscore is the right idea.

At the first glance I thought underscore looks pretty daunting, but after I compared space with underscore, I really cann't tell which one is better.
I think space seems to be a little bit cuter but the underscore helps me more to understand that it is a file extension, Although I'm okay with both I think.

[aonez]

maybe disabling the check box below when the check box above is not selected will help user understand the relations of the two check boxes

You can disable the subfolder check and still have an intermediate folder/subfolder created, in cases like there are more than one items or using the option through the Finder Extension. But clearly I'll use "subfolder" just to be more consistent.

think space seems to be a little bit cuter but the underscore helps me more to understand that it is a file extension

That's the point, an space could be missed but an underscore is more visible so the user can noticed something changed there :)

[aonez]

@KLszTsu I'm closing the issue now since it's been fixed already :)

Thanks again for all the feedback!

[KLszTsu]

Thank you very much!
You are the best developer I've met in a while ☕