Hacker News Reader

Comment by tjoff | Hacker News Reader

Then again, for many tasks, a tree truly is the best way to structure files (start broad and then home in on a file even if you have no clue about the filename or what the file contains or even the type of the file) and any file management system that doesn't recognize this is seriously flawed.

I got hooked by WinFS (then again it was many many years since I last heard anything about it), a traditional filesystem with a database layer on top seems like a good start.

View on HN

Truly? So, what is the best way to make a hierarchy of, say MP3s:

- year-performer-composer-star rating

- genre-year-song title

- album title-song title

- ...

You get the same problem almost everywhere. Is it year-project or project-year or maybe customer-year-quarter-project?

Yes, for many tasks, a tree is a good way to structure information. The problem is that the choice of tree can be widely different for different tasks (for example, 'that song you played last week', 'that minute-long guitar riff by X')

I think a hierarchy should be like an index in a database: set by an expert to match the most common access pattern, but not enforcing other access patterns. Hierarchical file systems are good at the former, but atrocious at the latter.

And we sort-of already have WinFS, in the form of full-text indexes on file systems.

Well without a tree structure you're still going to have an issue with the names.

Personally I use Album Artist/Album/DiscTrack. Artist - Title.ext

But say we did away with folders - you'd have to put all that data in the filenames to sort properly anyway!

Naaaaaah, you'd just have metadata!

I think the last time I used the filesystem to browse my music was in 2003. And it was dreadful. I use a music library app in which I can decide which way my music is ordered. Albums from oldest to youngest? No problem. Artists alphabetically? Sure thing. Artists alphabetically and their albums in chronological order? No problem.

The music library app is especially tuned for ways to view my music that make sense for music. It makes those easily accessible. The file system is wholly inadequate for that task.

The library app takes care of the underlying folder structure – but that’s an implementation detail I absolutely do not care about. I don’t even know how it looks. (I just looked it up, it’s “Artist” – “Album”, the same structure I used before I started using a library app.)

I’m not sure that the file system is really so bad (at least I’m relatively comfortable with it) but I do think that for certain specialized tasks it’s massively preferable to have dedicated apps. Music and photos are my two prime examples.

"Albums from oldest to youngest? No problem. Artists alphabetically? Sure thing. Artists alphabetically and their albums in chronological order? No problem."

from the "to each his own" file: i have never understood why anyone would care about sorting their music in any of these ways. To me, none of these are ways to "view my music that make sense for music." On the other hand, I find a directory structure for albums and everything else chucked into a giant directory to work just fine, as it supports the sort order I do sometimes care about, mtime. Normal search tools like locate work pretty well too.

In previous comments on related articles on HN, I have pointed out that files, and to a lesser extent directories, are good because they serve as a universal protocol-of-sorts for dealing w/ blobs of data. That allows you to use the system that works for you, and me to use the system that works for me, and yet we can still share files and move between systems etc. with little headache.

I am actually sympathetic to moving to a tag-like system that supports hierarchical tags (gmail style), so that multiple organizational structures can be imposed onto a mess of files. I also find it funny that that's more or less how unix file systems work under the hood.

All of these music filing schemes fail miserably when confronted by Classical music. There you often have four 'obvious' candidates for leading tag---composer, performer, conductor, title etc. There is even an entertaining amount of discussion on the net about the best way to solve the problem. The only point of commonality accepted is that the iTunes approach simply does not work. Then every one starts to bang their personal agenda drums; all sadly out of sync. And this for a subject that every one 'knows' Move into other areas and you will find similar problems. This does not even begin to touch the problem of tagging as a speed bump---takes time, ask a librarian :)

How much music do you have? 100 songs?

I have 5,380 titles, I cannot for the life of me imagine how to deal with that inside the confines of the file system. I want to browse my music. (It probably doesn’t help that I despise search. Search is no alternative to browsing for me.)

(Besides: This is not some evil scheme. Metadata for music is completely standard. My music library app – and every popular music library app – puts music in straightforward human-readable folders. That’s a nice fallback if all else fails – but to me it is just that. A fallback.)

I have 3575 music files on my current main hard drive, organized by hand into an /Artist/Year - Album Title/File.ext structure just fine. I don't listen to classical music or by genres, though.

I have around 69,000 and I find that due to the fact that most music players choke on that amount, that often sorting by filename is one of the fastest ways to get my music into a decent order.

Also in response to other post - you can quickly rename your music with something like Musicbrainz Picard (cross platform) or foobar2000 (Windows).

for the record, I too have about 5000 tracks these days.

I use both. I've got about 10,000 tracks sorted as Artist - Album/Song.ext in the filesystem. Since I'm a bit of a geek about my music anyway I remember which song is where anyway and if not, there's still find.

In the music player (mpd + ncmpcpp as a client) everything's sorted using tags so I can do all the searches I ever want quickly.

The filesystem way of storing things is merely about redundancy and whenever I want to copy stuff onto an external device. I do not want to use an app to sync stuff onto my smartphone. That's just an extra app for a trivial task. Additionally it provides me with a tad more control. And seriously? I couldn't care less about copying over all MP3s recorded by a band Z in year X belonging to genre Y (or some other sort of query). When I copy music to the phone I'll copy albums and that's what this file structure is absolutely perfect for.

Don’t you browse your music? I’m very particular about my music collection and I definitely need to browse it. Sometimes I just do not know what I want to listen to, so search is useless. And looking at something like all albums from 2009 (because I know some good music came out then) can be very useful for me.

I do not care about the structure on the disc. I use my music library app to browse.

I said that many things are well represented by trees, not all things...

And we sort-of already have WinFS, in the form of full-text indexes on file systems.

We have nothing like WinFS in practice, we don't think or use our filesystem as if it was a database. That is the key difference, not the implementation.

Agreed. For example trees of source code seem to fit the hierarchical structure very well, because it can (almost) map directly to projects, modules, submodules and classes, and conveniently separate them from e.g. build products or configuration files. Trees are not evil, but they are not the holy grail of file management either.

From a historical point of view, a traditional filesystem with a database layer on top seems to be the most logical way to go. Personally, I think it would be interesting to see what would happen if someone did it the other way around: create a whole new way of organizing files that doesn't use trees, and allow layering some kind of 'tree view' on top of that.

If not for a specific few lines of code explicitly forbidding hard linked directories, all of the modern file systems would actually be directional graphs.

> start broad and then home in on a file even if you have no clue about the filename or what the file contains or even the type of the file

But this file system does not construct itself and if you made a mistake while sorting a file you hit the search field after a while anyway, because you can't find the file in any subfolder. You're right, a mixture of both will probably the next step. But it seemed to me that MS isn't trying something new with windows 8 and the metro interface, did they?

Reply on news.ycombinator.com