aonez / Keka

The macOS & iOS file archiver
https://www.keka.io
4.86k stars 240 forks source link

Use ditto when creating .zip (PKZip) to preserve the resource forks in .zip archives #802

Open MaxPower85 opened 3 years ago

MaxPower85 commented 3 years ago

Since ditto can preserve resource forks in a .zip (PKZip format) archive just like the Archive Utility can, without using .tar, there should be an option that uses ditto to create such archives.

This preserves resource forks with hidden files inside a hidden __MACOSX folder inside the .zip archive ditto -ckX --rsrc --sequesterRsrc --zlibCompressionLevel 9 folder1 folder1.zip

This preserves resource forks more like how it is when you use tar, with hidden files inside the archive, but without placing them inside a hidden __MACOSX folder ditto -ckX --rsrc --zlibCompressionLevel 9 folder1 folder1.zip

Regardless which of those two you use, the Archive Utility turns the resource fork data from those hidden files into actual resource forks upon extraction... so those files are visible when you list the contents of the .zip archive in Terminal, but when you list the contents of a directory with ls after the extraction, those don't appear anymore, since they just get turned back into resource forks... but having a hidden __MACOSX folder might be preferable if the archive is also shared with Windows users, for archivers that just extract those hidden files with resource fork data as regular files that are visible on Windows, so those files wouldn't be all over the place.

To avoid confusion, the current "Exclude Mac resource forks" option should be renamed to something else (maybe to "Clean up macOS specific hidden files", since that seems to be the only thing it is doing now and that it isn't related to actual resource forks), as mentioned here https://github.com/aonez/Keka/issues/571

Also... it would be good to have some tooltip that would tell users when they put their mouse pointer over it what kind of files that option actually excludes, so they wouldn't get an impression that it's for something else.

There could be another option then to exclude the resource forks, which should not then appear on 7zip's tab if it doesn't support resource forks anyway and it also shouldn't appear for other compression formats if they are used without tar, since the resource forks also wouldn't be preserved without tar if someone just uses .gz or .xz... and when then option is selected for .zip, then maybe it could just use the 7z binary to create the .zip archives, since it is multithreaded (although compressing to .zip is relatively fast anyway) and when it's unchecked it could just use ditto to create .zip archives.

That way, I think it should be very clear to users who don't know much about what they need to do to preserve the resource forks what they should use to preserve them.

aonez commented 3 years ago

This preserves resource forks with hidden files inside a hidden __MACOSX folder inside the .zip archive ditto -ckX --rsrc --sequesterRsrc --zlibCompressionLevel 9 folder1 folder1.zip

This preserves resource forks more like how it is when you use tar, with hidden files inside the archive, but without placing them inside a hidden __MACOSX folder ditto -ckX --rsrc --sequesterRsrc --zlibCompressionLevel 9 folder1 folder1.zip

I'm seeing both lines identical. Where was the change?

I see two issues to use ditto in Keka. First it does not use multiple threads, so will be very slow compared to p7zip. Second it does not report any kind of progress, although this is not that important any maybe can be guessed checking copied data.

Anyway I can try it.

MaxPower85 commented 3 years ago

I'm seeing both lines identical. Where was the change?

Sorry 😂 ... the 2nd one was meant to be without the "--sequesterRsrc" part... I copied just the 1st one and meant to delete that part in the 2nd one, but I guess something distracted me and I forgot 😂

I'll edit it, so it wouldn't confuse others

MaxPower85 commented 3 years ago

I see two issues to use ditto in Keka. First it does not use multiple threads, so will be very slow compared to p7zip. Second it does not report any kind of progress, although this is not that important any maybe can be guessed checking copied data.

I was exploring what's the easiest way to preserve resource forks in a regular zip archive without using tar... and ditto just seems to be one of the easies and most compatible ways to do it...

But... I was trying out some things with some Terminal commands... I'll write more about it in a separate post a bit later...

Briefly, I found a way to get resource forks preserved even inside of 7z archives or any other archiving format by just using Terminal commands and what already comes with macOS to create those files to save the resource forks in archives and to recreate resource forks from those files after the extraction... it's not difficult to do, so it could be added to Keka very easily even in next version... and Zip archives created in such a way seem to work just fine with the Archive Utility... the Archive Utility seems to recreate the resource forks properly for all files that had them from such archives and it also seems to work fine when they are extracted by ditto.

There's just a small issue.... for whatever reason, some other popular archivers/unarchivers don't seem to recreate all the resource forks properly from such archives upon extraction, even if they can do it when a zip was created by the Archive Utility... soooo maybe I need to explore it more to see what's the difference between those archives and ones created by the Archive Utility and why do some other archivers have issues recreating resource forks from such archives if they don't seem to have an issue with ones created by the Archive Utility directly.

What's making it kind of difficult is that saving resource forks inside archives doesn't really seem to be well documented... searching Google for it doesn't seem to be much help on this topic... but if it seems too difficult to find a solution to create archives with resource forks in a way that works well for those archivers that have those issues, maybe we should just report it as a bug to them with a solution for they can fix it.