Hacker News Reader

Comment by st3fan | Hacker News Reader

This feels like a very user-hostile attitude ...

Also, these files provide a useful service to Mac users. You could also find a way to support them instead of fighting this.

View on HN

You hit the nail on the head. It provides a useful service to 'Mac' users. To literally every other OS user these files are considered bloat and slow the system down for everybody. Hell, linux users performing searches on these directories get duplicate results for every file a mac has touched.

I appreciate it may come across as a bit hostile towards the users, but in reality in a budget constrained environment where we cant make it perfect for everybody, we must make sacrifices to make the majority of users have a better experience. In my opinion mac users not having metadata of when a file was last modified pales in comparison to the rest of the business searches taking twice as long on samba shares.

.DS_Store is one file per directory, and it's a dotfile too so it should be hidden by default from most *nix commands.

Thankyou for correcting me. I was speaking from old knowledge as this was a while ago I set this up and couldnt quite remember exactly how the .DS_store system worked. I thought it was one .ds_store file per file.

That being said, depending on your business and data structure this doesnt detract from the point. Also if you have a deep nested directory structure with no real files in it, would every level contain a .ds_store file?

There is one .DS_Store file per directory. It contains information like window size, icon position, folder background, thumbnails, etc. Deleting/vetoing .DS_Store files will not hurt anything of substance - other than discarding user preferences.

There are also AppleDouble (._) files, which are one-per-file. These contain the file's extended metadata and resource fork. Deleting these _may_ cause data loss if there's anything important stored in the resource fork. A better option is to enable vfs_streams on your Samba server to allow storing the additional forks natively on your filesystem (e.g. as xattrs).

(If you're using a modern Windows file server, I believe the resource fork is automatically mapped to an NTFS alternate data stream.)

See:

https://www.samba.org/samba/docs/current/man-html/vfs_stream...

There is also the (evidently dying) principle of by default wanting control over my computer and filesystem. I know this is not compelling to most people anymore but I feel like if I want 25 files in a directory, I expect to see 25 there. Not 26 because the operating system really really really really wants to pollute it with one more file. I want 25 there. If I wanted that other file there, I would have explicitly commanded my computer to put it there.

I also object to my operating system running all these background processes on MY computer without me commanding it to, and it suggesting on its own that I do this or run that, again in absence of any command to do so. More and more, operating systems and applications are treating MY computer as a dumping ground and science experiment: for things it wants to do, instead of what I want it to do.

I should not have to go off and find a setting somewhere just to stop my operating system from doing things on its own I don’t ask for.

It's an impedance mismatch. You're moving files between a system that supports multiple streams per file (data fork + resource fork) to a system that has no concept of different streams (POSIX). The extra stream has to go somewhere, or you get data loss.

It's worth noting that almost all modern file systems support multiple streams. NTFS has alternate data streams, Ext4 has xattrs. Modern SMB and NFSv4 also both support this at the protocol level.

The problem arises when you're using Samba (without vfs_streams enabled), or you're writing to a legacy FAT filesystem, in which case you start getting the AppleDouble files - again, to prevent data loss.

>but I feel like if I want 25 files in a directory, I expect to see 25 there.

What about linux that would have 27 in this case?

For plenty of users "control over my filesystem" means being able to put an icon in a certain position and have it stay there when they come back to the folder.

The .DS_Store file contains macOS Finder's view preferences for the directory. Finder will only write a .DS_Store file to directories where a user has actively altered their view preferences for that directory (e.g., switched from icon to list view, “cleaned up”/rearranged icons, etc.). Just navigating through the directory doesn't create a .DS_Store file.

Perhaps you were thinking of AppleDouble files.

Isn't there also the fseventsd file?

They also can tank SMB performance on macOS. Apple even suggests to disable them in large environments for performance.

https://support.apple.com/en-us/HT208209

Why is it necessary to index .DS_Store files, though?

Isn’t that what’s making searches slow, not that the files exist? Why do you suppose that this isn’t a problem for Macs too?

I believe you're thinking of the AppleDouble files with name ._file. Those haven't really been used for the past 10 years or so (unless you run software older than that, obviously).

> Also, these files provide a useful service to Mac users.

With respect to DS_Store files on shared network drives, that is not true. Such files provide utility to a single Mac user, whichever uploaded the DS_Store file to that directory last. This file is used to store user preferences, which breaks as soon as there are two or more users with different preferences. Simply put, it does not belong on shared network drives at all.

> Simply put, it does not belong on shared network drives at all

My home NAS file shares are used by only me, so I'd like it to be supported there. So at the very least it needs to be configurable per-share. And in that case, having the server admin add them to veto lists seems like the easiest solution.

Sure, but not on shared network drives. A network drive only used by a single person is another matter. (And probably not very common, though I also have one.)

> These comments are also stored in the extended file attributes,[5] but Finder does not read those.[6]

They already have a solution but they're not using it?

Reply on news.ycombinator.com