Live data from Hacker News

Death to .DS_Store

aorensoftware.com

41–50 of 127 posts

Re: Death to .DS_Store

#41
post #22

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.

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.

Re: Death to .DS_Store

#42
post #7

Earlier quoted context omitted.

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…

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

Re: Death to .DS_Store

#43
post #16

Earlier quoted context omitted.

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.

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.

Re: Death to .DS_Store

#44

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?

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 POS…

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.

Re: Death to .DS_Store

#45

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?

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 POS…

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

Re: Death to .DS_Store

#46

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?

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

Re: Death to .DS_Store

#47
post #6

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.

Re: Death to .DS_Store

#48

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

Re: Death to .DS_Store

#49

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 i…

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.

Re: Death to .DS_Store

#50
post #23

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.

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?
Post reply on HN