[DidYaWipe]

Not to mention that it's an obnoxious and incompetent design. Look at the fact that Mac OS litters every other computer it visits with turds, for its own (and in fact only one user's) benefit. It's doubly stupid because the next browsing Mac that comes along trounces the previous one's turd.

If Apple wanted to store view settings for remote volumes (or even local volumes), the competent design would have been to store them locally (and per user) in a central location on the machine doing the browsing.

I remember the promised re-write of Finder and thought it never happened. Nothing seems to have improved for the user. I could post a list of decades-old defects that persist today.

The one thing I can think of that has finally been fixed (and this was long after the "rewrite") was that you can now finally sort the file list properly: with folders at the top.

Now I wish someone would explain something that might actually be worse than DS-turds: the presence of a "Contents" subdirectory in every goddamned Apple package. I mean... who thought you needed to create a directory called "Contents" to hold the contents of the parent directory? It's mind-boggling.

[ryandrake]

> Not to mention that it's an obnoxious and incompetent design. Look at the fact that Mac OS litters every other computer it visits with turds, for its own (and in fact only one user's) benefit. It's doubly stupid because the next browsing Mac that comes along trounces the previous one's turd.

It also kind of reveals an underlying attitude of the OS developers: That it's OK to use the user's filesystem (particularly directories owned by the user as opposed to the OS) as their dumping ground for all this metadata. As if it's their hard drive rather than mine.

I'm OK with Apple putting whatever it wants in /System and /Library, but I'd expect the rest of my filesystem to contain only files I put there.

Same goes for you, Microsoft: You can have C:/WINDOWS and I should get the rest of the filesystem.

[jwells89]

> That it's OK to use the user's filesystem (particularly directories owned by the user as opposed to the OS) as their dumping ground for all this metadata.

There are more of this type of offender than I can possibly count that dump myriad dotfiles and dotfolders in your home folder on nixes instead of adhering to platform conventions or XDG or anything, really. Worse, these programs won't function properly if you set your home folder to be read-only (leaving subdirectories writable) to keep it clean. Drives me nuts.

[ryandrake]

Oh, yea. I didn't mean to give Linux/Unix a pass. Those systems can be equally cavalier about leaving their configuration droppings all over my filesystem, too.

[pasc1878]

The issue is where does this information go.

If in a central place what happens if the original directory is moved - how is the metadata updated. - Unix is another file somewhere, Windows can be in the registry.

With Apple it is kept with the directory.

The issue is that a directory needs some metadata and the Unix design of everything is a file does not allow the directory to include this without adding another file somewhere.

The POSIX file system is not the perfect thing.

[smallstepforman]

You really want to look at Haiku. The only sane hierarchy for desktop OS’s. Native apps respect the hierarchy, however some ported apps create garbage .files where they shouldn’t (Haiku reserves /home/config/apps/name/… for garbage). /system is read only as a bonus

[ulbu]

oh man, don’t get me started on gui applications usurping the Documents folder.

[jwells89]

I can see the appeal for removable media, at least. It’s pretty common for those to have only a single user toting them around between home/work/school and for that case it makes a lot of sense to store that info on the media so settings stick across different machines. It probably made even more sense back when removable media was the norm for data transfer because network access was spotty or slow.

It really should be turned off by default on network volumes though.

[lyu07282]

The funny part is actually that its not supposed to create DS_store everywhere:

> There is also an unfortunate bug that is not fixed to this day that result in an excessive creation of .DS_Store file. Those files should only be created if the user actually makes adjustments to the view settings or set a manual location for icons in a folder. That’s unfortunately not what happens and visiting a folder pretty much guarantees that a .DS_Store file will get created

I get the sense that if you are annoyed by it, you aren't the target audience of Mac OS, the target audience are technologically illiterate people for who it really doesn't matter (they barely know what folders are anyway), so to Apple there is no reason to ever invest any effort to fix it.

[DidYaWipe]

By that logic, though, there was never any reason to implement it in the first place.

[tekknik]

> Now I wish someone would explain something that might actually be worse than DS-turds: the presence of a "Contents" subdirectory in every goddamned Apple package. I mean... who thought you needed to create a directory called "Contents" to hold the contents of the parent directory? It's mind-boggling.

It’s because not every bundle does include that folder. Here you go: https://en.m.wikipedia.org/wiki/Bundle_(macOS)

[mathnode]

I will raise you- desktop.ini and thumbnails.db

[tredre3]

Windows is polite enough to not write them on network shares, unlike .DS_Store.

[lazide]

Now, yes. It used to be a really irritating problem there too.

[wasabinator]

That's still a weaker hand. macOS also has the ton of ._ files. Would have been better to have folded than raised

[pasc1878]

No macOS does not.

The issue is the file system.

Apple file systems allow a file to have extended attributes or resource forks. Thus a file is not a simple stream of bytes.

When you copy a file to a file system (e.g. FAT) that does not understand these attributes macOS copies those to a ._ (I think if the file system was NTFS then you could probably convert them but I don't think anyone does)

Copying a file out of an Apple environment loses data (OK the data is metadata and usually no one cares)

[pxoe]

back in windows xp days yes, it's pretty much never a problem nowadays. for the past...almost two decades, actually - thumbnails get stored in user profile folder since vista. (though it is different for network folders and may still be a problem.) and desktop.ini files - you'd only ever encounter them in predefined system folders (like pictures, etc.) or if you manually customize a folder in its properties - customize tab (like changing folder "type" to one like those predefined folders or changing its icon, not the same as changing size/thumbnail size/columns/etc though, that's stored elsewhere too)

[threeseed]

> the competent design would have been to store them locally (and per user) in a central location on the machine doing the browsing

Not sure but it could be the case that when you mount a network drive there isn't a stable identifier that can be used to track it.

[organsnyder]

Sure, that wouldn't work if the network volume was accessed by different URIs. But it would work in 95% of cases, which is good enough.

[DidYaWipe]

Exactly. And if the same machine used two URIs, there'd simply be two entries for settings. And the settings cache could flush old entries periodically.

[nullindividual]

Like two websites that look the same, except one captures your creds?

You don't want user prefs to apply to multiple locations solely based on URI.

[organsnyder]

Just because two URIs might appear to be similar doesn't mean they are identical. Using the URI string as a hash key wouldn't be vulnerable to this.

[Wingy]

Store a single .DS_Store in the root of the disk that stores either the reference or all of the data for that filesystem?

[threeseed]

Users rarely mount network drives as root so not sure how this would work.

Also the conflict resolution to support concurrent updates would be crazy.

[DidYaWipe]

I think it's likely that there is a reasonably stable path for any kind of mount, but I don't know a ton about networks so I'll leave it to someone else to weigh in.

But the stakes are very low here, so settings can be invalidated and discarded if they can't be resolved or they age out of the local cache. And if the mount is of a type that can't be reliably identified later, the default should have been to do nothing. Spewing junk all over every computer visited, especially junk that won't even survive the next Mac user's visit... is amateur-hour and obnoxious at best.

[dang]

We detached this subthread from https://news.ycombinator.com/item?id=40870645.