4 ms·

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 i

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.

threeseed 2y ago
> 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 2y ago
  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 2y ago
    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 2y ago
    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 2y ago
      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 2y ago
  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 2y ago
    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 2y ago
  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.
mathnode 2y ago
I will raise you- desktop.ini and thumbnails.db
- tredre3 2y ago
  Windows is polite enough to not write them on network shares, unlike .DS_Store.
  - lazide 2y ago
    Now, yes. It used to be a really irritating problem there too.
- wasabinator 2y ago
  That's still a weaker hand. macOS also has the ton of ._ files. Would have been better to have folded than raised
  - pasc1878 2y ago
    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 2y ago
  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)
deleted 2y ago
[deleted]
jwells89 2y ago
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.
ryandrake 2y ago
> 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.
- ulbu 2y ago
  oh man, don’t get me started on gui applications usurping the Documents folder.
- jwells89 2y ago
  > 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 2y ago
    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 2y ago
      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.
dang 2y ago
We detached this subthread from https://news.ycombinator.com/item?id=40870645 https://news.ycombinator.com/item?id=40870645.
lyu07282 2y ago
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 2y ago
  By that logic, though, there was never any reason to implement it in the first place.
tekknik 2y ago
> 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) https://en.m.wikipedia.org/wiki/Bundle_(macOS)

threeseed 2y ago

> 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 2y ago
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 2y ago
  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 2y ago
  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 2y ago
    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 2y ago
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 2y ago
  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 2y ago
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.

mathnode 2y ago

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

tredre3 2y ago
Windows is polite enough to not write them on network shares, unlike .DS_Store.
- lazide 2y ago
  Now, yes. It used to be a really irritating problem there too.
wasabinator 2y ago
That's still a weaker hand. macOS also has the ton of ._ files. Would have been better to have folded than raised
- pasc1878 2y ago
  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 2y ago
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)

deleted 2y ago

[deleted]

jwells89 2y ago

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.

ryandrake 2y ago

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

ulbu 2y ago
oh man, don’t get me started on gui applications usurping the Documents folder.
jwells89 2y ago
> 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 2y ago
  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 2y ago
    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.

dang 2y ago

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

lyu07282 2y ago

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 2y ago
By that logic, though, there was never any reason to implement it in the first place.

tekknik 2y ago

> 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) https://en.m.wikipedia.org/wiki/Bundle_(macOS)