.DS_Store | Hacker News Reader

.DS_Store

en.wikipedia.org

71 pointsrubyn00bie21 comments

That's not the only problem. Apple leaves a whole bunch of "mac droppings" all over the place:

https://github.com/github/gitignore/blob/master/Global/macOS...

The worst part is that .DS_Store assumes, even on remote (SMB) filesystems, that only one machine will ever be accessing the directory, and so stores things like view settings and icon positions and such. Which means that every mac computer that accesses that file share will be fighting with each other, overwriting their metadata, and sometimes triggering problems because one has half-overwritten the file while another is accessing it.

That metadata should have been stored locally on the mac (with info about what path it refers to), not on the remote system.

Overall, it's a very poorly designed feature.

But it was pretty neat that you could arrange icons on a floppy disks and then give it to someone else and the icons were in the same position on their computer.

It’s still relevant today for external drives.

Disk images, which is how a lot of mac software is distributed also use this feature.

My guess as to the reason they’re in the directory rather than a separate folder is so you can rename/move it without losing all your metadata.

The filesystem already keeps track of moves/renames -- I can (and have) moved the files that the App Store downloads, and it still knows where they are.

Veto'ing these files on Linux SMB servers along with ".thumb" files is one of the most satisfying things I have ever done as a network administrator.

[1]: https://www.samba.org/samba/docs/current/man-html/smb.conf.5...

Just seeing this post among the others activates my instinct to delete the title.

7M+ .DS_Store on GitHub - https://github.com/search?q=filename%3A.DS_Store&type=Code

These temporary files are terrible! I don't know which major Windows version started with the ".thumb" and "desktop.ini" files, but if I tell my OS to navigate and display me contents of a folder, please don't change anything in that folder! You should be assuming "read-only" as often as possible, and only assume anything else when explicitly stated to do so.

But instead, they create thumbnails. In the very same source folder. Shouldn't this stuff go on some cache in your windows directory?

Another thing is that 'System Volume Information' created on removable drives. And Android too creates its directory structure on every mounted drive..

The wikipedia links to a similar article on the windows thumbnail cache, where it claims from Vista onward that Windows has a central cache location for thumbnail caches.

Ah yes, that explains why "thumbs.db" is no longer a thing and was mostly remnants left over from the XP days...

Think about the amount of man hours people have spent deleting these files from repositories, USB drives, archives... They spread like a virus.

When I set up new fileshares at work I used Filescreen templates to stop those being created on network shares (Example [1]).

Gnome creates it's own too, and I wish it would stop - the only solution seems to be to recompile libgio with the trash method redirected to delete[2].

[1] https://dea.nbird.com.au/2014/11/19/windows-server-prevent-m...

[2] https://askubuntu.com/questions/229098/how-to-i-stop-ubuntu-...

I thought those files were a compromise when apple went to OS_X and got rid of the old "resource fork" park of the mac OS finder system. This data was part of the file, and let the operating system know which program to open the file with (even if it didn't have a .ext). But it made it hard to interopt.. But I might be a little off.

https://en.wikipedia.org/wiki/Resource_fork

http://mirror.informatimago.com/next/developer.apple.com/doc...

I have been glad these are user-visible files rather than some obscure FS metadata (xattrs) that get lost or propagated unpredictably by various tools.

The way they did it means I can delete 'em or keep 'em depending on what I want to accomplish and that the'll work on any filesystem.

This has lead me to the idea of a “gitignore” for HN article title names.

Not a bad idea.

This is analogous to desktop.ini on Windows Explorer, or .directory on KDE Dolphin.

I got data loss when OLPC's Sugar desktop did this. I put the SD card into the machine to undelete something, and Sugar promptly overwrote my data by adding some useless nonsense desktop file.

For all these sorts of things, I really truly think "How dare they!" and much worse. It fills me with rage that an OS would do this.

Reply on news.ycombinator.com