Instead of having one directory in the root (__MACOSX) that can be easily deleted, the thumbs.db files are in every directory of the extracted data. These of course can be deleted using a find command, but it is a real pain in the rear! I would rather delete one folder than have to find hundreds of files!

I use both OS X and Windows, so I am used to dealing with the oddities of both… remember that there is two sides to everything, you’ve only experience your side of it because you are on Windows. Come to the other side and experience from a Mac perspective and you may start saying “the way Micrsoft does it is not only wrong, but stupid and unnecessary!” ;-o)

However, wow… Talk about bias! “More and more people are using Mac’s for development these days … Several plugin and theme authors for Wordpress also develop on Mac. While this is a good thing …” It’s good? Why? I don’t think I’ve read anything so funny before! That statement is ironic when this article itself is about a superfluous subject.

The Compress (formerly Archive) command in the Mac OS X Finder creates zip-compatible archives but does not use the zip command (nor will unzip interpret the __MACOSX directory correctly). The “ditto” command with the “-k” (zip-compatible) option can create these archives and extract correctly from them, and the ditto man page gives an example of mimicking the Finder’s Compress command from the shell.

The information contained in __MACOSX contains all manner of things that cannot be expressed in simple file systems and simple archive formats. There are old-style Mac resources in there sometimes (though not so much these days, as they are obsolete). Mostly, the extra information is extended attributes and metadata. Mac users would not be happy if it were lost.

Those who want just the simple bytestream and nothing else should avoid the Finder’s compress command and instead use one of the solutions that other posters have proposed (or just run zip from the shell).

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.

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…

unzip() {
/usr/bin/unzip “$@” -x ‘__MACOSX/*’
}

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

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.