More and more people are using Mac's for development these days. As an example, a lot of the core developers from some of the leading web frameworks use Mac as their primary development platform. Several plugin and theme authors for Wordpress also develop on Mac. While this is a good thing, there is one particular side effect of this development that annoys me beyond relief.
It seems that the easiest way to archive something on Mac is to right click on your directory of choice in Finder and select “Archive as…”. This creates a Zip file, which then the developer can distribute to users. The problem is that Apple, like many other software giants, tends to twist and bend the user's will and interpret what the user wants to mean something else. In this case, the natural thing for the OS to do is pack up that directory, and ONLY that directory in a Zip file. But no sir, how can that be? How can Apple “transparently” embed some metadata in the Zip file so that if some other Mac user opens it in Finder, he/she can benefit from this metadata.
Apple does this by creating another folder suspiciously named __MACOSX at the root of your Zip archive. Here's an example (its the Cutline theme):
0 02-02-07 12:37 Cutline 1.1/
12292 01-31-07 17:16 Cutline 1.1/.DS_Store
0 02-02-07 12:38 __MACOSX/
0 02-02-07 12:38 __MACOSX/Cutline 1.1/
82 01-31-07 17:16 __MACOSX/Cutline 1.1/._.DS_Store
82 01-31-07 00:12 __MACOSX/Cutline 1.1/._ie6.css
238 01-30-07 23:59 Cutline 1.1/ie7.css
82 01-30-07 23:59 __MACOSX/Cutline 1.1/._ie7.css
0 09-13-06 17:30 Cutline 1.1/images/
12292 09-13-06 17:30 Cutline 1.1/images/.DS_Store
0 02-02-07 12:38 __MACOSX/Cutline 1.1/images/
82 09-13-06 17:30 __MACOSX/Cutline 1.1/images/._.DS_Store
65705 09-11-06 15:55 Cutline 1.1/images/header_1.jpg
34365 09-11-06 15:55 __MACOSX/Cutline 1.1/images/._header_1.jpg
62867 09-11-06 15:59 Cutline 1.1/images/header_2.jpg
33224 09-11-06 15:59 __MACOSX/Cutline 1.1/images/._header_2.jpg
82708 09-11-06 16:01 Cutline 1.1/images/header_3.jpg
34855 09-11-06 16:01 __MACOSX/Cutline 1.1/images/._header_3.jpg
59780 09-11-06 16:03 Cutline 1.1/images/header_4.jpg
33555 09-11-06 16:03 __MACOSX/Cutline 1.1/images/._header_4.jpg
This folder contains, among other things, thumbnails for images in the original archive. Now, this kind of unwanted, undesirable outcomes just really really annoy me. But I'll try to keep my cool, and present a systematic analysis of not only why what Mac OSX does is wrong, but also stupid and unnecessary:
-
No surprises: As a user, I don't like surprises, specially of the bad kind. If I request to archive a directory into a Zip file, thats exactly what I want. If I later unarchive that zip file, I should get my original directory back. Nothing more, nothing less. Any kind of unintended behavior is BAD.
-
We are not stupid: If I wanted you to stick in an extra folder named
__MACOSXin my archive, I'd let you know. Your users are a smart group, don't insult them like this -
I hate clutter: In my Wordpress themes directory, I unzip Cutline. If each theme starts creating its own
__MACOSXfolder, then my themes directory would soon get cluttered with needless garbage. -
It breaks things: If MacOSX did something harmless, like embed some metadata (like Zip file creator) into the Zip file itself, I might have been OK. But creating an entire tree structure in the archive just breaks things, in ways more than one. As an example, if like Cutline, each Wordpress theme started creating
__MACOSXfolders in the root of the archive, then later if I install another theme, I'll get lots of errors and file name collissions because the new theme will also try to extract in the__MACOSXfolder. Not only this, some programs (like Gallery and Wordpress) have the ability to load plugins/images directly from Zip files. As a result, I'll end up with unwanted images, themes and plugins in my setup. Not only this, it might actually just break your installation. Since you did not create the__MACOSXfolder yourself, you don't know what is in it, and it might not always obey the expecations of the software. -
Security: Again, you did not explicitly create that folder. What if someone creates a virus, that just modifies the default zip program on Mac to sneak in malicious payload via the
__MACOSXfolders in any new Zip archives you create? Apart from the security risk, its a time sink. Why should I go around cleaning up mess that I did not create? Software is supposed to make my life easier, not harder. -
Redundant: From the looks of it, it seems that all of the data inside the
__MACOSXfolder is created from the original directory. No external information is used/needed. If thats the case, why oh why would anyone EVER need this stupid new folder? If some metadata is needed, it can always be reconstructed from the original on demand. This seems downright stupid to me.
Would someone, anyone, please explain Apple's intent and motivation behind this “feature”? What are the benefits (if any)?
26 Comments
hey dude, wat shit u wrote? i AM SMART AND UNDERSTAND TAT IT’S BAD and all wat i waana ‘now is – CAN i delete this folder after extracting and tat it won’t cause any damages to my files!
Alex You are a muppet. If YOU SHOUT AT PEOPLE they are unlikely to help you.
Diwaker – I agree, it does seem very stupid to be doing this. I wonder why they actually do it though.
i am just trying to find a solution … a software… what will NOT create those “hidden” files…
I’m not positive on this but I do believe that the __MACOSX directory is created on purpose because older OS X applications actually use the resource fork. Not including this would cause said programs to break. It also has something to do with the HFS filesystem that it uses. I also don’t think there is a way to intelligently guess if something is using the resource fork, so they include it in the archives.
So you can do 1 of 2 things:
1) Buy a Mac – from the sounds of it you could use one.
2) find . -name “__MACOSX” -exec rm -rf {} \;
Calm down and stop yelling. That superfluous folder you speak of is nothing but the resource fork of the .zip archive. Nothing to get worked up about.
Also, the plural of Mac is Macs, not Mac’s. Learn your basic punctuation.
*@john*: Thanks for correcting my punctuation. Meanwhile, I don’t see any reason why I should suffer for a retarted way of doing things. It is _not_ “nothing but a …” as I have already explained in my post.
It gets more confusing when the Mac user then sends that file to a Windows user. Can I even use this Mac zip file?
We were having this issue with one of the macs at my office. Since the directory structure of the zip file is traversed, this is causing some problems, but for some reason when I right click in Leopard to zip, my mac isn’t creating that file. It might be because I have stuff it installed, but I’m not sure.
Here’s a zip program for MAC users that does not create the __MACOSX file
*@brian*: thanks for the pointer. Though I’m a bit surprised (and disappointed) that they want to charge a fee for such a trivial software. In any modern programming language you could probably write a Zip archiver yourself in a few lines that doesn’t create those stupid files.
If you don’t want that stuff in you zip file, don’t create an Archive! If you archive, OS X puts everything in there it needs to restore the original content.
If you want a ZIP file, create one! Use the terminal:
zip -r cutline.zip ‘Cutline 1.1′
P.S. I just found there is a Automator Action (can be saved as a Finder Plug In) which creates “clean” Archives http://mikepiontek.com/software/mac/create-clean-archive.html
I see lots of mac fanboy here..
I see lots of mac fanboy here.. and i lol a lot at you ;)
Many thanks for the info…I feel that the Macs will soon go the way of Microsoft and start becoming more and more retarded and caring less and less about the end user, as they are becoming increasingly popular at an exponential rate. It’s sad but it’s a very human reaction to being presented with an advantage…since Vista is like the equivalent of computational Herpes, people are running in droves to Apple; but instead of just maintaining themselves as a company that puts the end user first, they will take advantage of the situation. Just like with the I-Pods…In actuality, they do what Microsoft does, only much better. In a sneakier, “spider-ensnaring-flies” kinda way…and it’s SO easy too. I hope that they realize that they need Microsoft to be #1 though, just like BugerKing needs McDonald’s to be #1.
@VII: for the sake of everyone involved, lets hope that doesn’t happen! I haven’t owned a Mac yet, but I am seriously contemplating buying a Mac Book Pro for my next laptop :) But you make an interesting point. I wonder how the Apple fanboy/fanatics would feel if Apple did indeed become #1 in the market. Would they still feel as cool?
@ Diwaker Gupta : It’s the same with everything else that’s popular, after awhile everything that becomes mainstream becomes the new subject of hatred, not always just because of the simple fact that it’s now mainstream, but oftentimes because those that are accepted into the mainstream simply don’t know how to act when it comes to the increased power they have over they’re customers. It’s terrible that things are that way EVERYWHERE. We really need to go back to the days when corporations (and governments >_>) used to fear their fickle customers and aim to please them by any means necessary. Soon they’ll be talking about how, “back-in-the-day” Macs used to be for purists…
their* ……………..lol
Hey how about the ATT00004.htm files and ATT00007.txt files that are created when sending mail from MAIL.APP to Outlook. Would like to prevent these from happening too. Suggestions?
Hey how about the ATT00004.htm files and ATT00007.txt files that are created when sending mail from MAIL.APP to Outlook? Would like to prevent these from happening too. Suggestions?
“If I request to archive a directory into a Zip file, thats exactly what I want. If I later unarchive that zip file, I should get my original directory back.” which is exactly why the Mac embeds the resource forks in the __MACOSX directory. Otherwise you would not get back exactly what you Archived; there would be data-loss of those attributes. These can include: file-type, creator, custom icon and others.
I agree that when you unzip one of these on a non-mac (or with a non-resource-fork-aware unzip utility) you get cruft, which is easily dealt with via a “rm -r __MACOSX” command or using “uznip foo.zip -x ‘__MACOSX/*’ ” to unpack it.
It is no different that the .DS_STORE files that creep into mac zips, or the tumbs.db that creep into windows zips when there are images in the directory.
your points 2, 3, and 4 all fall prey to the fact that this is needed data for “get[ing] my original directory back”. I find point 5 flawed in that a malware capable of that could be putting copies of it self anywhere in your zip file: in .foo directories, replacing other files, etc There is no added security risk. Point 6 is incorrect because attributes like creator, customicon, and filetype metadata can NOT be recreated on demand from the file in any case where they were specified as non-default.
i use the following for zip and mail bound to apple-shift-z(the original is from macosxhints forum i think with a little bugfix):
nothing keeps you from using terminal though. or one of the various other freeware packing tools available. this resource fork is the reason why you see pictures instead of folders for certain zip archives onces theyre extracted. as for the collisions… nothing a little bit of force can’t fix ;p
property theMonthList : {mJanuary:1, mFebruary:2, mMarch:3, mApril:¬
4, mMay:5, mJune:6, mJuly:7, mAugust:8, mSeptember:¬
9, mOctober:10, mNovember:1, mDecember:12}
set temp to “lmr”
–set theFold to choose folder with prompt “Bitte Zielordner auswählen:”
set fileName to (temp & “-” & gib_Zeitstempel(current date))
on gib_Zeitstempel(theDate)
return ((((day of theDate) as string) & “-” & (Get_Obj(my theMonthList, “m” & month of theDate)) as string) & “-” & (year of theDate) as string) & “-” & ((time of theDate) as string)
end gib_Zeitstempel
on Get_Obj(theObj, theProp)
tell (run script “me
on f(theObj)
return theObj’s ” & theProp & ”
end f”) to return f(theObj)
end Get_Obj
tell application “Finder”
set theItem to selection as alias
set itemPath to quoted form of POSIX path of theItem
set ZuErsetzenText to name of theItem
set theFolder to POSIX path of (container of theItem as alias)
set zipFile to theFolder & fileName & “.zip”
do shell script “zip -r -j ” & (quoted form of zipFile) & ” ” & itemPath
– delay 1 — this may be needed (and adjusted) for larger folders?
try — We don’t need to say anything if there are no .DS_Store files
do shell script “zip -d ” & (quoted form of zipFile) & ” ‘*.DS_Store’”
end try
end tell
tell application “Mail”
set theMessage to make outgoing message
tell theMessage
set zipFile to (zipFile as POSIX file) as alias
make new attachment with properties {file name:zipFile} at after the last paragraph
end tell
set visible of theMessage to true
end tell
Presuming your unzip executable is in /usr/bin, and that you’re using the bash shell, you can fix this problem once and for all by putting the following in your ~/.bashrc
unzip() {
/usr/bin/unzip “$@” -x ‘__MACOSX/*’
}
Doesn’t make sense to me. They should have just used the UNIX filesystem standard of a ‘.’ prefix in the directory name. Created a “.macosx” and kept the metadata in there. Also, I wonder what happens if the user creates a directory called “__MACOSX”? Escape characters? Or will it just disappear into the void of meta-data nothingness?
Since most Windows users and a lot of Mac users tend to “hide’ dot files from themselves, this could result in the buildup of junk over time. Better to hang it out there and let the user decide if they want it or not…
This is a helpful script for automatically creating a clean (no __MACOSX dir) archive from the Mac itself: http://junecloud.com/software/mac/create-clean-archive.html