Decompressed files do not inherit attributes of the compressed file #176
Comments
|
I think this is quite important. |
|
Hi, can you (or somebody else) test if creating a .cpio file using Archive Utility.app (to be found in /System/Library/CoreServices/Applications/Archive Utility.app ) preserves these attributes? I do not know what to look out for to test this myself. Greetz |
|
I think you may have misinterpreted the issue I posted. When Mac files are downloaded by a Quarantine savvy application, such as Apple's Safari, Messages, iChat and Mail, a "Quarantine" attribute is added to those files as a flag that they have recently been downloaded and need to receive a security check before use. When a compressed file is uncompressed, all the files need to inherit that same attribute or they will not be security checked before opened. The issue you raise might also be a problem, but would need to be raised as a separate issue. |
|
Oh, now I understand correctly. |
aonez
changed the title
|
@alvarnell Must check that one for sure. |
|
@alvarnell I've just uploaded a test build with this functionality, could you check? |
|
Yes, it did retain the Quarantine attribute after zipping and decompression, which is the critical thing here. But it did drop these additional attributes, which admittedly are of less importance"
com.apple.lastuseddate#PS 16
com.apple.metadata:kMDItemDownloadedDate 53
com.apple.metadata:kMDItemWhereFroms 489
|
|
@alvarnell I'm not sure about |
|
It looks like this is making extraction way slower. I noticed it while extracting a compressed .tar.gz file with thousands of files inside (and I discovered the option in the new version of Keka was enabled by default). For my case I just disabled the option since it was not needed for that specific archive. I just wanted to share my experience, maybe there is a way to make the implementation faster. |
|
Thanks a lot for the feedback @ioemilio! Indeed that process may take some time. Already did a performance boost while in beta testing. The last test was a file containing 66K files and applies the quarantine in 1 second approximately. Can you let me know how many where on that file? I just got the number using: find <DIRECTOY> -type f | wc -lAlso knowing the disk you're using (HDD, SDD, USB connected...) and your CPU can help me reproduce your speed. Thanks anyway! 😄 |
|
The number of files in the archive is roughly 30K for an overall size of roughly 450MB uncompressed. I have an early-2015 MacBook Pro with a 2.7GHz Intel i5 and the default SSD. The archive is on the SSD. During the extraction I was not doing any other intensive task (just browser, mail client, probably some other app, and the usual background application). I would not have noticed 1 extra second to apply the quarantine. I just tried to measure the time needed to extract the archive with the option "Inherit quarantine from downloaded files" disabled and enabled. While the normal extraction (with the option "Inherit quarantine from downloaded files" disabled) takes about 45 seconds on my pc, the quarantine application takes another extra 6 minutes and 15 seconds (plus the 45 seconds for the extraction)! |
|
Thanks for the followup @ioemilio! Just occurred me to ask if you're using the latest version of Keka because I've enhanced the speed in 1.2.0 RC in early October but earlier versions were applying the quarantine in a single thread. I've did my test with this file: boost_1_74_0.tar.gz About 130MB (650MB uncompressed). Can you check if it lasts that much with this file too? |
|
I updated to version 1.2.2 (before I had 1.2.0) and tried extracting the file you provided (boost_1_74_0.tar.gz). Unfortunately applying the quarantine is still very slow (comparable to previous version). |
|
Also for me, Keka 1.2.2 (4199) and boost_1_74_0.tar.gz quarantine step took 5m30s. I'm on 10.14.6 |
|
Does Keka hang during the quarantine process in your cases? |
|
Can you check if in the Console.app there's a message like: default 16:50:09.540168 +0100 Keka database is locked |
|
Yes, I see many of those. |
|
Keka does not hang at any point (checking Activity Monitor) |
|
Thanks Matt! In my tests worked as expected in 10.14 and 10.15 but reproduced the issue in a 10.13 virtual machine. Not sure yet why this is happening, will keep you informed. |
|
Yes, I also have a lot of them (about 200 in a couple of minutes). The message is always the same:
Moreover Keka is not unresponsive, but the UI is very laggy while extracting the file. |
|
This is a build with the single-thread application of the quarantine (used before 1.2.0 release candidate): I'm still not sure what's the reason for the issue. The multithread method is WAY faster when it works properly, but this single-thread build will be faster than what you're experiencing now. |
|
@ioemilio @gingerbeardman can any of you check if that build fixes the issue for you? It should take less than a minute to apply the quarantine of the boost package. Thanks in advance!!! |
|
For me it is faster than before. The single-thread version you linked took 2 minutes and 30 seconds to apply the quarantine (while it was roughly 6 minutes for the multi-thread version). |
|
The single thread build took ~ 0m45s for me. |
|
Thanks booth of you! I’m gonna use the single thread in v1.2.3 and try to rework the multithread option for the future... |
|
Version 1.2.3 released with the single thread application. Hopefully I can implement the multithread in the near future. |
At least with .zip files, but probably others, the unzipped files do not inherit any of the attributes that were assigned to the downloaded .zip file, most importantly, the quarantine attribute that allows macOS security features (Gatekeeper and XProtect) to check for known malware.
The text was updated successfully, but these errors were encountered: