Hacker News Reader

Comment by taftster | Hacker News Reader

> That said, never seeing another .DS_Store should be a system-wide option!

Yes please.

.DS_Store, .fseventsd, .Spotlight-V100, .Trashes, and ._this and ._that

These can all die in a fire too, as far as I am concerned. macOS loves to treat the user's filesystem as its own personal garbage dump.

thumbs.db and those weird MS alternative stream files for recording origination.

filesystem attributes are for decorating files with meaning. Anything else that attempts to use filesystems in "interesting" ways is silly.

Apple and MS really ought to consider why they do this sort of fragile, idiosyncratic nonsense.

But... thumbs.db is precisely not an "attempt to use filesystems in "interesting" ways" — it's literally a just hidden file with previews stored in it. Storing the preview in the alternative stream of the file with the picture itself would be "an interesting way".

Agreed. Where else would you put that stuff? It’s gotta go somewhere, and this is the least surprising place IMO. Anywhere else would have to be a parallel store that follows filesystem mounts and unmounts, renaming directories, etc so that it alway perfectly mirrors the thing it’s configuring.

> Where else would you put that stuff?

A "Centralized thumbnail cache" in the user profile folder, where it's been for a long while.

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

> so that it alway perfectly mirrors

Who cares? It's a cache.

That windows takes an approach does not mean it’s a good idea.

And what about things like folder settings, such as whether to display is as a list or as icons, or how to sort it, etc? That’s more important than a thumbnail cache.

In the particular case of thumbs.db, storing them in NTFS alternate data streams would have been a good idea; they're essentially caches for the main data stream, so if they fail to copy to different filesystems it's totally fine. Of course, that wasn't viable because 1) IIRC that was before the widespread adoption of NTFS, and 2) they probably still need the cache somewhere for vFAT USB drives.

Put it in $ProgramData for system-wide usage or whatever the user version is for individuals.

A hidden file is exactly what I said initially - a daft local decoration. Instead of using a stream, this one uses an attribute instead.

Put your data where it makes sense on the filesystem but don't dump arbitrary databases of information on there utilizing filesystem attributes because that is incredibly fragile.

thumbs.db only makes sense if the client is Windows (and only from a particular version onwards, until it doesn't). In the real world (starting with my laptop, running Ubuntu) it does not make any sense at all and is just a pain.

I don't want to see your thumbs.db or your weird ~{temp office files} either. Why do you insist on crapping on my nice neat file system?

> Put your data where it makes sense on the filesystem

Right near the data it's derived from is the most obvious place, you know, and makes sense for most of the application developers (it may not "make sense" for you but so what).

> Why do you insist on crapping on my nice neat file system?

"Your" neat file system? What a quaint notion. Two thirds of the hierarchy inside of your $HOME belongs to the OS you use and the tools you use (not "your OS" and "your tools" — just because you use something doesn't make it yours, you know). Your data is yours, of course, but the disk space belongs to the system harness first, and to you second, and the same applies to the file and directory organization.

Or at least that seems to be the prevailing attitude of most of the software.

> thumbs.db only makes sense if the client is Windows (and only from a particular version onwards, until it doesn't). In the real world (starting with my laptop, running Ubuntu) it does not make any sense at all and is just a pain.

Wait, didn't Nautilus use to read thumbs.db if it was present in the folder? Or am I thinking of some other file manager?

And .DS_Store is just your folder level preferences in Finder. If you don’t use Finder they won’t be created

Yes. And truthfully, I try to remember to only ever navigate my project folders (particularly those under revision control) using command line and/or IDE folder views.

But eventually, for whatever reason, I use Finder to go looking into a directory structure and bam, now I have .DS_Store. gitignore takes care of it, I know, but still, it's annoying.

> Thumbs.db

Windows has been storing thumbnail cache in the user profile folder since Vista (2006).

It's been 20 years. Time to let it go.

OTOH, If you want the information contained in those files, where else would you save it?

To me it seems more sensible to store information relevant only to this OS in a specific cache somewhere within that OS. It would even make cache-like functionality such as evicting old entries super easy.

There are some tradeoffs. Like if you used a usb and set up folder colours or any of the other things stored in the file, they would not move along with the usb when used on another computer.

If I set a folder colour in Finder on my work MacBook, and then plug that USB drive into my personal computer which uses Thunar as a file browser on Debian, nothing would happen.

And? If you mount a Unix file system on another system, you may see ‘invisible’ fuels whose name starts with a period, may even see weird files named “.” or “..”, may not see ACLs, and may not see any file attributes such as user and group information.

In 1970 it already was not true that one could treat all filesystems the way Unix did, but it certainly isn’t true anymore today.

> sensible to store information relevant only to this OS in a specific cache somewhere within that OS.

For most of these files, this isn’t information that can be reconstructed, so caching isn’t an option.

Also, the information has to move with the disk, if it is moved to or mounted on another system.

Reply on news.ycombinator.com