
Death to .DS_Store - snielsen
http://www.aorensoftware.com/blog/2011/12/24/death-to-ds_store/
======
templaedhel
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...](http://floatingsun.net/2007/02/07/whats-with-__macosx-in-zip-files/)

~~~
maaku
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 :(

~~~
keeperofdakeys
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.

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

------
MattBearman
Why did they change they article to a link to the google cache? Google has
since re-cached the page, and the cache now links to itself.

I was clicking on that link for hours before I realised, what a way to spend
christmas.

~~~
megablast
Well, I guess for the obvious reason that they couldn't handle the hits.

~~~
sirn
IMHO, the first thing to do when you could not keep up the traffic is to use
Coral Cache.

Just redirect to your.domain.com.nyud.net/article. Done.

------
sjs
For git users:

    
    
        echo ".DS_Store" >> ~/.gitignore
        git config --global core.excludesfile ~/.gitignore
    

If you spend many man hours dealing w/ .DS_Store files in source code repos
you're doing something wrong.

~~~
snielsen
Nobody individually spends too much time on dealing with them. It the global
accumulation of man hours having to deal with them that is a travesty.

~~~
masmullin
Find . -name ".DS_Store" | xargs rm

Forgive if it's not exact, I'm on a mobile device. But that should save you
effort.

~~~
jlarocco
Right, I don't think anybody is saying it's an overburdening difficulty.

But it's still _something_ , when I shouldn't have to do anything.

~~~
dextorious
It's an extreme case of what is commonly called a "first world problem".

~~~
jlarocco
90% of the "problems" discussed on HN can be dismissed as "first world
problems," but thanks for pointing it out.

~~~
dextorious
A lot, maybe, but not 90%. I think most are valid engineering problems and
questions

------
gregschlom
Related: The former lead of the OS X Finder explains the origins of .DS_Store:

<http://arno.org/arnotify/2006/10/on-the-origins-of-ds_store/>

------
stickfigure
WOW - the best feature here is that Total Finder enables cut-and-paste to move
files!

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".

~~~
glhaynes
Lion lets you move copied files by adding option to your paste: option-
command-V.

~~~
gregschlom
Which is the dumbest way to fix this issue:

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".

~~~
glhaynes
Because in some subtle ways, it's very different from the standard user
interaction — if one cuts a piece of text from a TextEdit document, that text
disappears immediately. That seems undesirably unsafe in a file system
explorer, though, which is why Windows doesn't delete a file that's been cut
in Explorer _unless and until_ it actually gets pasted somewhere else. This
puts a burden on the user to remember that a seemingly-identical interaction
works differently in Explorer than it does elsewhere in the system.

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.

~~~
wvenable
Windows dims the files when you cut them, giving you a visual indication. This
is pretty similar to how cut and paste works in Excel too.

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.

------
overshard
As someone who has to deal with coworkers who keeps sending me .DS_Store files
in every compressed archive, folder, and new project commit. I agree, this
must die.

I even have a script built around just cleaning .DS_Store from these items.
This should not be something that I need...

~~~
jws
Unix users are offended by all the useless carriage returns in HTTP too, (and
heaven forbid source files) but there just has to be some tolerance if we are
all to get along.

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.

~~~
drivebyacct2
Funny, I'm on a Linux system more often than Mac or Windows and the carriage
returns drive me insane. Also, because the Windows users on my team are the
ones that can't manage to figure out how to get their IDE or Git to leave our
line endings alone. Our least performing team member dominates our git stats
because he repeatedly manages to change nearly every line of code in our
project.

~~~
dcosson
Weird, the windows git client defaults to "checkout windows line endings,
commit unix line endings" or something to that effect. I do a lot of data
analysis and end up transferring text files manually and having to worry about
carriage returns all the time, but I've never had that problem with git.
There's an easy command line utility called flip [1] that makes dealing with
line endings pretty simple. But yes, it is a ridiculous thing to have to worry
about.

[1] <https://ccrma.stanford.edu/~craig/utility/flip/flip.cpp>

~~~
ludwigvan
It might be TortoiseGit perhaps. The command line msysgit works sanely afaik.

------
hwatson
Google Cache:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://www.aorensoftware.com/blog/2011/12/24/death-
to-ds_store/&hl=en&strip=1)

Mirror of Google Cache:
[http://mirror.henriwatson.com/notmine/aorensoftware.com/deat...](http://mirror.henriwatson.com/notmine/aorensoftware.com/deathtods_store.html)

------
philwelch
I think it's indicative of the bikeshedding tendency of HN that we've spent
this whole thread bitching about the hidden .DS_Store file and none of it
admiring his work hacking the Finder.

~~~
jvc26
Yeah - its easy to be distracted by the .DS_Store in and of itself. I found
the method that led to him discovering the culprit fascinating!

------
falava
Disable .DS_Store for network drives:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

<http://support.apple.com/kb/ht1629>

------
alexhawket
I use TotalFinder as a finder replacement.

It has a feature called "The Asepsis feature" which will redirect .DS_Store
files to /usr/local/.dscache. Quite handy.

~~~
Brajeshwar
TotalFinder have actually de-coupled Asepsis from it.
<http://asepsis.binaryage.com/> is a free download.

~~~
specialist
Came here to say this. Thanks.

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.

------
eslachance
That's interesting... The PC equivalent is thumbs.db, which can be disabled
through a simple OS option. One of those rare occasions where a PC is actually
more user-friendly than a Mac. Oh wait, did I just open Pandora's box?

~~~
seanp2k2
Windows has always had more configuration than OSX.

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...)

~~~
jodrellblank
You must be thinking of the Linux fantasists registry, not the real one, as
the real registry has Windows ACLs and users can only write to HKCU by
default, admin rights are needed to write to HKLM or HKCR.

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).

~~~
keeperofdakeys
_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.

~~~
WayneDB
"Nearly all configuration files are in one of two places"

That's entirely incorrect. There are many, many programs out there that do not
follow the convention.

~~~
keeperofdakeys
I can think of no system services that don't use /etc. As for user programs,
the only real things that I can think of breaking this convention are small
projects that store their configuration files with the binary; usually small
programs that run from their own directory. Would you care to elaborate on
where these other programs choose to store their configuration?

~~~
ams6110
Not unusual for third party software to have configuration files elsewhere
though. You see this a lot with "Enterprise" java stuff, typically config
files in XML scattered around the installation directory.

------
esonderegger
I'm surprised no one's chimed in to complain about AppleDouble files. I
recently updated a machine that writes a lot of files to network shares to
10.7. Since 10.7 no longer supports older versions of AFP, this meant mounting
those shares using smb://. All of a sudden, instead of just .DS_Store, I had a
dot file for every new regular file to ignore.

It's definitely time for these to go.

~~~
Lazare
God, those are a nightmare. And unlike DS_Store you _cannot_ safely delete
them. Some apps/formats store critical info in them. (some fonts and some fcp
projects, at a minimum. Good thing we had backups.)

------
joelackner
blueharvest is a pay mac os app that does this:
<http://www.zeroonetwenty.com/blueharvest4/>

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).

~~~
ashcairo
TinkerTool allows you to disable the creation of those files on network
drivers.. It's free too.

TinkerTool.. let's you tink, without leaving a stink?
<http://bresink.de/osx/0TinkerTool/details.html>

~~~
stfn
There is a built-in option to disable .DS_Store creation on network and
removable drives. Run the following in a terminal then log out to restart your
session.

    
    
      defaults write com.apple.desktopservices DSDontWriteNetworkStores true
    

source: <http://support.apple.com/kb/HT1629>

------
seanp2k2
While definitely a fun read, this problem has already been solved by
BlueHarvest and TinkerTool <http://www.zeroonetwenty.com/blueharvest4/>

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.

~~~
fauigerzigerk
Unless you want to know how stuff works.

------
frou_dh
I have a LaunchAgent (~cron job) that zaps all .DS_Store files on the entire
partition on a timer. I mainly did this so that Finder windows always use my
default view settings.

I used to be similarly annoyed by Windows Explorer taking it upon itself to
use weird custom views depending on directory contents.

------
svisstack
what a stupid move with this link..... i dont belive someone could do that he
pastes link to google cache because of what? pay less of traffic some amount
of text? google recached this page and article can't be viewed

------
Malic
This is great for an individual user but what about a whole department/company
of Macs?

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.

------
tszming
To prevent .DS_Store file creation over `network connections`, there is a
simple method: <http://support.apple.com/kb/HT1629>

~~~
funkah
> Disabling the creation of .DS_Store files on remote file servers can cause
> unexpected behavior in the Finder

Not much of a solution. Also these files should not be written by default, if
at all.

------
conradev
This is a dirty hack indeed. Mac OS X really needs a stable, feature-rich code
injection platform. CydiaSubstrate, where are you?

------
gcv
Path Finder is a fantastic Finder replacement, far more powerful, and does not
create .DS_Store files. Highly recommended.

------
funkah
Yeah, this is one of those annoying little dinguses that just makes OS X look
crappy. In any file share or similar shared space, only one person has to
browse it with a Mac to drop these little turds all over the place.

~~~
hexley
Thumbs.db

------
wavephorm
Junk files like this being littered across filesystems just wreak of extremely
poor software engineering. I would love to see Apple stop writing software and
operating systems and just stick to hardware.

~~~
fiblye
But Apple doesn't actually make hardware, and their OS and hardware designs
are meant to be paired together.

OS X has some flaws, but I think it's better than the alternatives in the
market.

~~~
drivebyacct2
>Apple doesn't actually make hardware

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.

~~~
cwp
They design the hardware, but they don't manufacture it.

~~~
gkanai
Name a company in 2011 that designs AND manufactures their own computers.

~~~
cwp
Samsung.

------
balloot
I am a software engineer who works mainly on a Mac. I am fully aware of the
existence of .DS_Store files, but it has never bothered me nearly as much as
it bothers this guy.

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?

~~~
sounds
I am also a software engineer who works mainly on a Mac.

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?

~~~
Someone
I more admire his balls than his sophistication. Patching out a function
called 'FlushChanges' without precisely knowing what kind of changes it
flushes? I wouldn't take the chance that it does, as a side effect, increase
the risk of disk corruption.

~~~
JadeNB
But no one is asking you to take that chance. The author notes that there
_seem_ to be no ill effects; but how else can one find out, barring some
sudden forthcomingness on Apple's part, than by trying, which is exactly what
the author is doing—with reports (as the article says) forthcoming in case of
trouble?

