Hacker News Reader

Comment by templaedhel | Hacker News Reader

I have not encountered .DS_Store files enough for them to annoy me, but the same design flaw works itself into my life almost every day, in the form of zip files.

When zipping files on OSX, the common way is to right click on your directory of choice in Finder and select “Archive as…”. This creates a Zip file, with the unwanted addition of a _macosx folder. According to this [1] article, the folder is used for thumbnails, cache data, and other meta data. I have seen these folders work their way into github repos, and I am reminded of their uselessness almost every time I open a zip archive. In the past it may have been justified (to reduce cpu load generating thumbnails and cache files while unzipping), but just like .DS_Store, the time has come to abolish these folders from zip archives.

[1] http://floatingsun.net/2007/02/07/whats-with-__macosx-in-zip...

View on HN

This folder is needed to create a one-to-one mapping of file on disk with file in ZIP. The same thing happens when you put a file into FAT32 filesystem, which doesn't have support for HFS+ extended attributes. For example, if not for _MacOS folder, you wouldn't be able to store OS X aliases (not Unix symlinks but aliases) in ZIP, which use extended attributes.

Other solutions are 1) use some other archive format which supports extended attributes (e.g. XAR), 2) create ZIP archives without storing extended attributes, losing the ability to unpack exactly what you packed there.

Apple chose a compromise.

It doesn't sound like a compromise to me. The metadata is added in a way that is useless to all unzip programs except Finder.

The compromise seems to be that they made a Mac-specific derivative zip format, but in a very non-transparent way: it will work just fine for a long time, and then suddenly it doesn't work.

If you have essential metadata (such as aliases) they will still not make it across to a Windows user, and it won't have "just worked". In that case, you'd been better served by a warning when creating the zip.

It's not useless to other ZIP programs: you can unzip and zip back the directory with other programs and it will work just fine. The reason? They didn't make a derivative format.

Of course OS X aliases won't work on Windows -- there's no such thing as alias on this operating system. Just like Windows won't magically set Unix permissions on files extracted from ZIP archive created in Unix format. OS X specific things will be useless on other OSes.

In Mac OS X you can (or could at one time) attach extra meaningful data to a file, classically known as the "Resource Fork". In the pre-OS X days applications were often bundled by placing images, audio, etc. in the application file's resource fork. I remember in the 90's finding an application that had a huge (for its day) multi-megabyte resource fork, but only a few kilobytes of program data in the data fork.

That is what the "_macosx" folder contains, only these days the resource fork is only used to store cached data such as thumbnails, window positions, etc. But it didn't always use to be that way, and for compatibility's sake we're stuck :(

It doesn't matter if modern programs can read _macosx, the problem is modern applications creating them. Since they store useless metadata these days, there is no reason not to stop default creation of them.

My point is that they sometimes do store critical file data.

> I remember in the 90's finding an application that had a huge (for its day) multi-megabyte resource fork, but only a few kilobytes of program data in the data fork.

Heck, it wasn't uncommon for applications to have no data fork at all prior to the PowerPC transition. (PPC applications stored their object code in the data fork.)

I think this should be on top of this thread:

Asepsis http://asepsis.binaryage.com/

Asepsis is a system utility for prevention of .DS_Store files

Only for Lion, unfortunately. (Maybe everyone else has already upgraded.)

Reply on news.ycombinator.com