p7zip-project
Can you make 7zip not rearrange files in alphabetical order (when it writes them to .zip archives), so the __MACOSX folder and the AppleDouble files for resource forks / extended attributes could be added to .zip archives in a way that's compatible with archivers that support recreating resource forks / extended attributes from those?
As you probably know, preserving resource forks / extended attributes can be very important for some files like old Mac fonts... it's important for aliases that are created in Finder to work, it's used to preserve tags for files and folders, for custom icons (if you go to Get Info and apply a custom icon there)... etc.
Before I write some more detailed explanations... just to summarize...
7zip doesn't have to add any special support for resource forks / extended attributes for this to work (since AppleDouble files can be created using other utilities), other than to have an option to add a folder without adding the contents of the folder at the same time and to not sort all files in some alphabetical order when writing them to a .zip archive because the order in which AppleDouble files are added seems to be important for this to work properly and since AppleDouble files have filenames that start with "._", sorting them alphabetically just seems to mess up the order in which they should be added for this to work.
So... 7zip has to do less things than it does to make this work... Just having an option to add folders without adding anything from them (as with zip when you don't add "-r") and to not sort anything in some alphabetical order should be enough to allow users to add a __MACOSX folder with AppleDouble files (which they can create using other utilities) in an order that's compatible with archivers that can recreate resource forks from those.
Users could then sort the files to be added in a correct order with some script or if you want to make it easier for users to add whole folders (instead of adding files one by one in a specific order), you could maybe add a sorting option when someone is adding a __MACOSX folder with AppleDouble files together with some folder, to arrange the files inside the archive in a way that the AppleDouble file for a specific file/folder is written to the archive right after that file/folder. In other words, if you have a folder called "your_folder" and a __MACOSX folder with AppleDouble files for it, to not just add "__MACOSX" folder with everything in it first and "your_folder" with everything it in after that, but when you add a specific file from "your_folder" to the archive to add an "._" AppleDouble file to __MACOSX for that file before adding other files from "your_folder" to the archive.
Now for a more detailed explanation...
I did lots of tests to see what would be needed to preserve the resource forks in a way that seems to be fully compatible with both the Archive Utility and with the unar binary (which is used by different archivers and which seems to be more picky about the order in which AppleDouble files were added).
You can also test it by adding files in a specific order using the zip binary that is included with macOS, since the the zip binary does not seem to do anything special to preserve resource forks / extended attributes... it does not create the AppleDouble files and it does not try to sort them in some specific way... so that's why I'm mentioning it... as an example how to preserve resource forks even when using an archiver that does not really seem to do anything special to preserve them... the same could probably be done with any other archiver that can make a .zip archive, as long as it can add folders without adding everything from them at the same time and if it was just writing files to the archive in the same order as they were added, without trying to sort the files that were already added in some alphabetical order.
To create the __MACOSX folder with AppleDouble files, you can use a command like this (if you want to create it for a folder called "your_folder" in your current directory)
tar cf - your_folder | tar cf - --format cpio --include='*/._*' --include='._*' @- | ditto -x --norsrc - __MACOSX
BTW... Avoid trying to browse the __MACOSX folder in Finder, so .DS_Store files don't get created too inside of it (if that happens, Archive Utility seems to extract it as a regular folder)... Finder doesn't show the "._" AppleDouble files anyway, but you can see them with "ls -a" in Terminal if you want to see those hidden files.
I'm not saying to make 7zip create the __MACOSX folder with AppleDouble files automatically... users can do that themselves if they want... but if someone wants to add those to a .zip archive, so archivers that support recreating resource forks from those files would recreate resource forks upon extraction, those AppleDouble files should be added in a specific order for it to work properly... after you add some file (the "data fork" of it or the file as it is without resource forks / extended attributes), next file that should be written to the archive after it should be the AppleDouble file with resource forks / extended attributes for that file, before adding other files.
In other words...
If you have a folder called "your_folder" and inside of it you have "file1", "file2" and "folder1", inside of "folder1" you have "folder2" and inside of "folder2" you have "file3" (you can tag them all, to make sure they have resource forks / extended attributes) and you create the __MACOSX folder with AppleDouble files for it, the way you add files to a .zip archive in a way that seems fully compatible with both the Archive Utility and the unar binary when it's done with the zip binary from the Terminal is this order... there are two ways to do it that seem to be fully compatible...
1st way... you start by adding an empty folder, then you add the AppleDouble file for that folder, then add the files/folders from that folder and after each file/folder you add, you add the AppleDouble file for that specific file/folder
zip your_folder.zip your_folder/
zip your_folder.zip __MACOSX/._your_folder
zip your_folder.zip your_folder/file1
zip your_folder.zip __MACOSX/your_folder/._file1
zip your_folder.zip your_folder/file2
zip your_folder.zip __MACOSX/your_folder/._file2
zip your_folder.zip your_folder/folder1/
zip your_folder.zip __MACOSX/your_folder/._folder1
zip your_folder.zip your_folder/folder1/folder2/
zip your_folder.zip __MACOSX/your_folder/folder1/._folder2
zip your_folder.zip your_folder/folder1/folder2/file3
zip your_folder.zip __MACOSX/your_folder/folder1/folder2/._file3
Or this... this one seems more like what you get when you list a .zip created by the Archive Utility with 7zip, but it seems maybe less convenient to remember... since you add an empty folder first, then all of it's contents and AppleDouble files for all files and folders inside that folder in correct order... and when you don't have anything else to add to that folder, then you add an AppleDouble file for that folder... with the 1st method it seems easier to just alternative between the "__MACOSX" folder and the other folder...
zip your_folder.zip your_folder/
zip your_folder.zip your_folder/file1
zip your_folder.zip __MACOSX/your_folder/._file1
zip your_folder.zip your_folder/file2
zip your_folder.zip __MACOSX/your_folder/._file2
zip your_folder.zip your_folder/folder1/
zip your_folder.zip your_folder/folder1/folder2/
zip your_folder.zip your_folder/folder1/folder2/file3
zip your_folder.zip __MACOSX/your_folder/folder1/folder2/._file3
zip your_folder.zip __MACOSX/your_folder/folder1/._folder2
zip your_folder.zip __MACOSX/your_folder/._folder1
zip your_folder.zip __MACOSX/._your_folder
If some are wondering why that specific order... that order would make a lot of sense when reading a .zip archive from a CD or even from a HDD, so the AppleDouble file for a resource fork would be found right after the data fork... to avoid having to go back to the beginning of a CD just to find the AppleDouble file... since it's supposed to be part of the same file, but they just split it into data forks and resource forks on file systems that don't support resource forks and for archives.
Although the Archive Utility seems to also recognize the __MACOSX folder even if the whole __MACOSX folder with everything in it was just appended to the end of an archive (but it doesn't seem to recognize it if the __MACOSX folder with everything in it was written to the beginning of some archive before other files)... but that adding "your_folder" with everything in it first and then just appending the __MACOSX folder with everything in it to the archive does not seem fully compatible with the unar binary, which is used by different archivers.
At the moment, when you add the __MACOSX folder with 7zip for some folder, if you add it for a folder called "1", then 7zip arranges files inside the archive so that the folder "1" is written before the "__MACOSX" folder and the Archive Utility recognizes the __MACOSX folder in that case (but as I mentioned, other archivers could have issues if the whole __MACOSX folder is just appended to the end of an archive, instead of arranging files in a way I described earlier)... but if you add the __MACOSX folder for a folder called "your_folder", 7zip arranges files in a way that __MACOSX folder is written before "your_folder" and in that case even the Archive Utility just seems to ignore the __MACOSX folder.
BTW... Another way of adding AppleDouble files to archives without creating a __MACOSX folder is to add "._" AppleDouble file to the same folder after adding a file... so if you have "your_folder" and a files with file names like "file1", "file2" and "file3" inside with "._file1", "._file2" and "._file3" AppleDouble files for those files inside of that folder also, you add "file1", then "._file1" after it and then you could add "file2" and "._file2" and so on... that way of adding AppleDouble files is used for .tar and .cpio archives and it can also be used for .zip when creating a .zip archive from the Terminal.
Maybe you should make a script that arranges files and then it would be ok to add (if it's not there already) option to read file list from a file. That would make sense rather than making, more o less, general compressor to do such a feats.
