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  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.
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.
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.
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.
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 :(
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.)
Asepsis is a system utility for prevention of .DS_Store files
I was clicking on that link for hours before I realised, what a way to spend christmas.
Just redirect to your.domain.com.nyud.net/article. Done.
echo ".DS_Store" >> ~/.gitignore
git config --global core.excludesfile ~/.gitignore
Forgive if it's not exact, I'm on a mobile device. But that should save you effort.
But it's still something, when I shouldn't have to do anything.
find . -name '.DS_Store' -delete
This is the one thing I have missed terribly from Windows. It boggles my mind that Apple thinks all that clicking, rearranging windows, dragging, shifting, and dropping is a sane way to move files. Intuitive yes, but more painful than typing it out at a command line. Sometimes Apple gets stuck in "make it pretty" and forgets "make it useful".
1. You have to remember a new shortcut
2. If you forget and you paste with Cmd-V thinking that you did Cmd-X to cut, you end up copying the files, so you have to go back, re-select them, and delete them manually.
I just can't possibly understand _why_ they would explicitly think: "no, let's not use the standard user interaction here".
Apple's way puts a burden on the user of remembering a different menu item/key combo, but doesn't break the similarity of the cut/copy/paste interactions with those in the rest of the system. They've just chosen a different set of tradeoffs than Windows did for this engineering problem.
I'm actually not sure why anyone would defend the Apple way of doing this -- it's truly baffling. Windows has some terrible conventions and Apple has some terrible conversions -- we'd all be better off choosing the best of both then blindly defending one over the other.
MS Office does not have a proper clipboard, either. For example, in Excel, open-select-cut-close-paste does not do what one expects:
- cut does not delete data from the clipboard, but
sort-of marks it for a future move.
- close makes the app forget about that move,
clearing the clipboard.
- because the clipboard is empty, paste does nothing.
IIRC, the clipboard is even broken within a single document, but I do not remember details (something like cut-enter data in a cell-select destination-paste?)
I even have a script built around just cleaning .DS_Store from these items. This should not be something that I need...
You can probably augment your VFS dispatch functions to never report a .DS_Store file and to delete one and retry any time a directory remove fails and you'll never know they exist! Or you could just ignore them the way Unix users ignore carriage returns and Windows users ignore vi's tilde backup files.
Mirror of Google Cache: http://mirror.henriwatson.com/notmine/aorensoftware.com/deat...
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
It has a feature called "The Asepsis feature" which will redirect .DS_Store files to /usr/local/.dscache. Quite handy.
I love Asepsis. Those .DS_store files really bug me. Because I have to show hidden files to see Eclipse's .project and .classpath files, that means I also have to see the zillion .DS_store files.
Stupid, stupid file name choices by Eclipse.
(Period prefixes are default hidden on Unix, for all you Windows users.)
PS- TotalFinder is great too. Big improvement.
PPS- Tried TotalTerminal for a while. It's okay. iTerm2 is enough better that I switched.
"The Asepsis feature has been removed from TotalFinder since version 1.3.0
If you are interested in this functionality, please check out a separate project asepsis.binaryage.com.
For migration info please read asepsis.binaryage.com#migration."
OSX - supposed to be simple to use and the defaults are supposed to "just work" and make sense to most people (drag an "icon" to the "trash" to "uninstall" it made no sense to me)
Linux (old-school) - made for users who care about the details and will take days or weeks to set up their system. Arch is still like this. Stuff adheres to philosophical standards and POSIX.
Linux (new-school) - trying to be like OSX with the "sane defaults; just works in most cases" but also tweak-able as much or as little as you like. Fedora 16 is my current weapon of choice for work/dev.
Windows - the "bloated swiss army knife". It's trying to have the "sane defaults" of OSX with the configurability of Linux, but the architecture is all stupid and you get error codes in hexidecimal that say "an unknown error has occurred!". Going back to Windows after OSX or Linux is pretty awful, honestly. Really the only thing it has going for it would be "it's popular", so it's likely that someone else also had error 0x8BADF00D and knew how to fix it. Hating aside, Windows being not open-source really hurts when you're trying to fix/debug something -- you can tail the error logs until the cows come home, but unless you're a Microsoft developer, it'll probably be pretty opaque (OSX is sometimes bad about this too -- ever have fun with KEXT bingo?)
The solution, obviously, is to just have a damn cache of these somewhere ELSE on the system (but not the registry, because the registry was one of the worst software ideas OF ALL TIME. What other critical system database lets anything write to anywhere at any time? Smart, guys, smart...)
And "one of the worst ideas of all time" provided a system-wide centralised, standardised configuration database accessible from vbscript and command line, as well as app code, with user specific settings migratable between computers, values configurable by group policy from a central company wide location with MS supplied or customisable templates. A huge improvement on the previous .ini files and something still unmatched in the Mac or Linux worlds with config in arbitrary locations and formats (which, incidentally, let anyone write anything anywhere in a similar fashion).
You are a little wrong there about Linux. Nearly all configuration files are in one of two places, /etc or dot folders in the root of my home folder. I can't write to the files in /etc as a user, and the config files in my home folder only apply to me. (Incidentally, since most Windows users at home run as administrator, they have access to the system configurations).
Personally, I don't like the registry because it is a binary blob (and having .ini files spread everywhere is much worse). I like human editable configuration files spread out in a folder hierarchy. I can use the same tools to modify configurations as everything else, as (nearly) everything is a file. I modify configurations with a text editor, I copy the configurations as files etc. It also allows me to get a better understanding of the configurations, since I can easily have comments and can literally copy and paste between text editors to migrate partial configurations.
In terms of a networking environment, applying configurations from a central user server is probably easier with windows due to the nature of the registry. However, due to the separation of system and user configuration on Linux, this is not an issue. You have /etc configuration as part of a 'system image', and can update this using tools like puppet. Then you have your user configuration migrate with a users network filesystem.
Most UNIX users at home have sudo permissions - unless someone else is using you're computer there's no difference in typing a password compared to confirming a UAC prompt.
As part of the registry clutter backlash there has been a tendency for Windows applications to store settings in user or system-wide app data directories. I'm still not convinced by the move, but obviously it's the only way to achieve portable installs without using two different storage backends to support it.
That's entirely incorrect. There are many, many programs out there that do not follow the convention.
Application installation is the confusing part (stupid DMGs), but what's wrong with moving something to the trash to delete it? That's what you do with files, why should applications be different?
You are confused by it just because you've been trained to think that install and uninstall are specific procedures, but since apps are bundles on the Mac, the procedure could in theory be just a copy and delete.
Too bad practice is always more complicated than theory.
Mac has problems too. Ive been bit by the uninstall process more than once. What does a normal user do when they drag an app to the trash and it doesn't uninstall?
Actually I don't think any OS has solved installation completely. Android leaves configuration files cluttering up your sd card.
Having said that, your example is bad because:
- your "simple os option" is hidden in an advanced administrative tool called "Local Group Policy Tool" (or previously Registry)
- OS X has the same disable .DS_Store option hidden in a similar administrative interface (Terminal + defaults write ...)
desktop.ini is closer from a functionality point of view, but in practice I see much less of it compared to Thumbs.db.
Control panel > Folder options > Advanced tab > there should be an option called "disable caching thumbnails" or some such.
It's definitely time for these to go.
don't get me wrong, i think this needs to be fixed at a higher level to really squash the trails mac leaves on other servers (just browsing a network share leaves these behinds).
TinkerTool.. let's you tink, without leaving a stink?
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
The first important step of developing a tool is to look around to see if there is something that you can just use or modify slightly to fit your needs.
I used to be similarly annoyed by Windows Explorer taking it upon itself to use weird custom views depending on directory contents.
Good karma to anyone that knows some good Samba config-fu to prohibit/direct-to-null the creation of .DS_Store files on a SMB share.
Not much of a solution. Also these files should not be written by default, if at all.
OS X has some flaws, but I think it's better than the alternatives in the market.
I don't understand this comment. Apple absolutely makes their own hardware. They pride themselves on the A4/5 series processors and took meticulous care in designing the unibody styling that their laptops have.
But I still wouldn't want them to stop making software. I really enjoy using a lot of Apple's software and software available for their platforms.
This aspect of OS X sucks but it doesn't mean they should stop making software altogether. That is ludicrous. Lazy, lazy thinking.
Not to worry though, it only took them 20 years to decide that multiple-button mice, omni-sided window sizing and full-screen apps were at all useful. I'm sure that the removal of .DS_Store will be celebrated as a great new feature of Pious Puma in a decade or so.
IMHO, this falls into the category of "it's much easier to criticize someone else's design decisions than to make your own." How about you build an OS over the course of 15 years and then I can pick it apart and write hyperbolic rants about all the design details that annoy me?
Whether or not I agree with his choice to disable .DS_Store (isn't that _his_ decision, and we can just leave it be?) -- I am totally amazed at his persistence, and eventual success, to implement what he wants. The level of sophistication to live-patch a framework using mach_star is far beyond your ordinary level of interaction with the O.S. Forget about the non-portability or possible breakage on an update, this is _hacking_!
So I disagree with your rejoinder: how about you find a reasonably permanent solution to turning off .DS_Store?