Death to .DS_Store | Hacker News Reader

Death to .DS_Store

aorensoftware.com

287 pointssnielsen122 comments

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

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

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.

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

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.

It is a bit stupid... Surely just loading that small article WP must be thrashing their database. This works (for now):

http://viewtext.org/article?url=http%3A%2F%2Fwww.aorensoftwa...

This'll work forever:

http://cache.historious.net/cached/1628132/

That's what they said about Yucca Mountain and time_t!

* For small values of forever.

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

They could have just made a static version with wget.

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.

Heh. Self-referential cache: http://db.tt/qAfMnTjl

Here's a Readability link of the full article: http://www.readability.com/articles/geihcmwz?legacy_bookmark...

Gone too, try this: http://cache.historious.net/cached/1628132/

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.

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.

Find . -name ".DS_Store" | xargs rm

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

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.

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

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

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

It should work. The other way to do this is:

      find . -name '.DS_Store' -delete

I'm in lust with xargs

I noticed the other day that .DS_Store was already ignored globally, but I don't remember ever telling Git to do that. Is this perhaps just something that OS X Git installer is doing by default now?

No it doesn't. I think the homebrew installer does it, but I'm not sure.

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/

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

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

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

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.

Actually, in Windows, that "differently in Explorer than it does elsewhere in the system." is not 100% correct: there is no 'everywhere else'.

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

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.

Where did you learn that? (Honest question, I thought I'd read through most new features before I upgraded to Lion.)

Just saw it mentioned somewhere in all the coverage before Lion's release. Maybe Siracusa's giant review but probably saw it before that from some NDA-breaker on Twitter. :)

A shortcut in Windows for this is to use the right mouse button when dragging. That shows you the context menu when you drop the file, allowing you to choose between copy and move. An interesting thing is when you drag files on the same drive, it defaults to move. When the source and destination locations are on different drives, it defaults to copy.

Or pressing down the "Ctrl" key while drag and dropping normally.

Cool! I did not know that one. I also found out holding down "Shift" does the same for "move" and holding down "Alt" allows you to create a shortcut.

Doesn't Windows Explorer support ctrl-x & ctrl-v for moving files? It's a long time since I used Windows but I'd be surprised if it didn't.

It does, that's what the GP is saying.

Total Finder rocks. Tabbed browsing alone is worth the price of a license.

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

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.

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.

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

There's also dos2unix which is a standard package in lots of Linux distributions. It converts from and to Dos (i.e. Windows), Unix and Mac line endings.

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

I'd recommend talking to the rest of your team to work out a consensus. With git you'll need to agree on values for core.autocrlf and core.eol. Perhaps you can take advantage of the time of year to offer an olive branch?

This is a good use case for "git filter-branch" and a lecture along the lines of "stop doing that".

Google Cache: http://webcache.googleusercontent.com/search?q=cache:http://...

Mirror of Google Cache: http://mirror.henriwatson.com/notmine/aorensoftware.com/deat...

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.

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!

Disable .DS_Store for network drives:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

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

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.

Holy shit, I just bought a copy of this app and I don't even care about .DS_Store files. BEST Finder improvement ever. Thanks!

From the TotalFinder preferences menu:

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

Ahh thanks for the tip.. I didn't even realize my TotalFinder has not updated.

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

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.

Its worth pointing out that this can cause issues with Xcode 4.2 as described on http://asepsis.binaryage.com/#known-issues

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?

Since Linux has no such construct by default. Does that make it the most user-friendly?

KDE's Dolphin creates annoying .directory files.

I found Krusader to be superior to Dolphin, but that's perhaps I'm used to old two-pane way of file management (Midnight Commander, Norton/Volkov Commander, Windows Commander)

Many programs do something similar, for example vim creates file~ as backups. Using a graphical file manager, these used to annoy me. After switching to a terminal for file management, I can easily ignore them as if they weren't there.

What I ended up doing was having vim save backups and temp files to ~/.vim/backup and ~/.vim/tmp by adding this to my .vimrc:

    set backupdir=~/.vim/backup
    set directory=~/.vim/tmp

Of course these can also be relative paths so you can have a project save these to a local .backup directory too if you want to keep them near the files they relate to.

I think desktop.ini is more like .DS_Store than thumbs.db is.

Thumbs.db is the correct comparison in this case because we're talking about behavior i.e an unwanted file that is silently added and propogates.

desktop.ini is closer from a functionality point of view, but in practice I see much less of it compared to Thumbs.db.

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

You hit the nail on the head. As an Arch user, I find pleasure in configuring a clean system, and indeed I've been continually doing it for years. Since it's natural behavior for me, I find it all too easy to forget that most people, including the technically inclined, consider such constant tweaking to be undesirable. So as much as I want to say, "Folks, stop using Apple products -- for their SOPA support, for .DS_Store, for being un-Unixy, for an endless list of other reasons", I have to recognize that my values as a computer user are completely out-of-line with the people who find Apple's selling points to be attractive. The OP, however, sounds like he may be ready for a Linux or BSD.

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

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.

> (Incidentally, since most Windows users at home run as administrator, they have access to the system configurations).

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.

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

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?

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.

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

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.

I can go on for days on how the Windows installation process is broken (icons in the start menu, desktop, AND quick launch bar), but it can be a pleasant experience. The msi installer has the flexibility to have 0 UI screens. Just install and then exit. But the defaults are about 5 screens the user doesn't care about or want.

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.

Linux distro package management solves that, surely?

It's not opening up a Pandora's box to say that Windows is more user-friendly than a Mac in some aspects, and anyway you're using the phrase "rare occasion".

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

Wait, there is a config setting for thumbs.db? Care to share the location? How do I disable it?

Not on a windows box right now, so might be slightly off, but iirc, this should be:

Control panel > Folder options > Advanced tab > there should be an option called "disable caching thumbnails" or some such.

yeah. Apple doesn't like these kind of system options.

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.

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

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

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

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

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.

Unless you want to know how stuff works.

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.

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

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.

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

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

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

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

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.

Thumbs.db

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.

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.

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

Not to mention motherboards, batteries, keyboards, trackpads, and soon SSDs.

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.

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

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

Samsung.

I agree OSX on a whole may have other advantages but that doesn't mean Apple is really any good at writing software (eg iTunes, Quicktime) or gets off the hook for leaving behind stigma like DS_Store.

iTunes and Quicktime are old, bloated pieces of software, but some of their high-end software (e.g., Logic) is wonderful.

And what, be yet another Windows OEM? Lots of people have had that bright idea in the last 15 years. No thanks, there are enough of those already.

This aspect of OS X sucks but it doesn't mean they should stop making software altogether. That is ludicrous. Lazy, lazy thinking.

I don't think it's the lone anti-feature that causes this "ludicrous, lazy" thinking. Apple software is absolutely full of inflexible, careless and/or poorly conceived anti-features.

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.

Oh, please. This is a two way street. Ever tried backing up a bunch of Windows-based Office files to a Mac? Umpteen million temp files for each real file is a real win for users. See for yourself what kind of fun people are having with that: http://duckduckgo.com/?q=office+temp+files

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?

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?

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.

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?

Reply on news.ycombinator.com