[Joker_vD]

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

[kstrauser]

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.

[noisem4ker]

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

[kstrauser]

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.

[mook]

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.

[gerdesj]

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?

[Joker_vD]

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

[fingerlocks]

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

[taftster]

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.