[miki123211]

Folders as an abstraction don't really make sense beyond documents, though.

If your music is stored in a folder hierarchy, and can, in principle, be located anywhere, how do you index it to provide a library view? How do you distinguish it from random audio files that just happen to be ID3 tagged, but which you don't want as part of your permanent music collection? How do you efficiently react to deletion events? What happens if you delete an entire artist's worth of music from your music app? Should it delete the files, or only the library entries? If it deletes files, what if (some of) that music was in a folder that didn't contain any other files? Should that folder be gone too, or should you be left with an empty folder or hierarchy? What if the folder also contained a .nfo, is it good UX if it deletes the music and just leaves the .nfo?

If the only tool you have is a computer, everything is a file. If you're a music lover and not a computer enthusiast, you tend to think about albums, artists and playlists, and that's how you want to view your music collection.

[ndriscoll]

You index it with btrees just like everything else. You distinguish it by configuring which folders to watch. You react to events with inotify. You don't give your music app write permission to your library. It only needs to write its indexes and playlists. All of your other questions become irrelevant; you delete the files you mean to delete with your file manager. In practice, music is small and storage is cheap, so deleting seems like a weird use-case for an application dedicated to music. I still have files that have been migrating across computers for 25 years.

[philistine]

What if I want to look at a list of composers, but the folder structure is by artist?

What about playlists?

The limitation of the folder is that there’s only one.

[ndriscoll]

Your player scans your library and indexes/sorts it however you'd like. I think this is how basically every player with a library function works? Like jellyfin loads my library in the same structure I've had it for 20 years, and it gives me various ways to view by name, artist, release date, rating, etc. and builds search indexes. I just point it to the roots of my libraries.

I said it needs a place to write playlists (or write access to your playlist folder(s)).

I wouldn't do it this way, but there can be more than one folder containing the same file (hardlinks).

[giantrobot]

> Your player scans your library and indexes/sorts it however you'd like.

Which means the concepts of files and folders becomes immaterial. If a music player is only interfacing with a database of music metadata it doesn't matter how the bytes on disk are organized.

There's a reason there's been 30+ years of file systems trying to tack on database functionality (BeFS, WinFS, etc) or over the top metadata indexing (Spotlight, Lucene, etc) to file systems. The files and folders abstraction is not sufficient for non-technical users in many cases.

[ndriscoll]

The music player isn't the only thing interfacing with those files. Backups do. Network file shares do. Pendrives, dedicated music players, and children's toys that can load music do. The player changes over the years (winamp, VLC, amarok, clementine, jellyfin, etc.). Sometimes "apps" go wonky and the only way to fix them is to "clear user data", which is opaque, and you'd rather control that/be more selective.

I don't really care how the player stores its metadata (the secondary indexes it makes after the scan), but I don't want it mucking with the original data, which I've had and will continue to have far longer than the player. Files in a known format (e.g. .flac) offer a standard, common interface for storing that data that's easy to organize and exchange across computers.

Google drive also shows what a world where people don't use folders looks like: I can never find documents at work without a link even when I have an idea of what I'm trying to search for. Folders at least push the user to do some organization. GDrive happily encourages you to do none.