[rubenbe]

I actually have quite a simple structure that serves me well (your mileage might vary)

  projects/
    2023/
    2024/
      0000-something/
      0312-other-project/
      0419-hn-comment/

each year I make a year folder. And each project has a month + day prefix. Sometimes I want long term projects to pop up on top, so I prefix them with 0000 (or only make the day 00).

It is simple, works on any OS. Although on Linux I do have some helper scripts. And it is very easy to quickly make a directory and move files from downloads into this directory. Keeping the nesting only one level deep helps for the discoverability. (versus the YYYY/MM/DD pattern which uses an extra month level)

[julianeon]

I do something similar for relevant folders, where I organize by time.

I have a top level dir where I usually have what I'm working on at the moment - think "this day" or "this week".

When it's time to archive it, outside that time window, I created a folder, using this format, for example for today:

041924

I move all the files I created on that day into there.

As a person with a typical human lifespan, I see no need to use a "2024" string - I don't think I'll live to see 2100, and anything before 2000 isn't relevant. "24" is just fine.

And that's it. Time keeps rolling on, so the number of 'archive' folders keeps increasing, but they're small in size and easy to locate.

This works really well when you're creating not-that-unique standard files every day, btw, which is my use case.

[quesera]

> 041924

I can accept YY instead of YYYY, but surely YYMMDD is preferable due to sort order.

[julianeon]

The advantage of 041924 is that, when changing directories from the terminal, you can type 0419 and tab the rest of the way (99% of the time the only completion is 24). It's more efficient. If I prepended the year, I'd have to type out 240419 every time.

[progx]

Why not use folder dates for that? It could be sorted.

  projects/           | 01.01.2017
    something/        | 01.01.2024
    other-project/    | 01.01.2023
    hn-comment/       | 01.01.2022

[jabroni_salad]

My experience with metadata is that a lot of applications don't care about its integrity but will never mess with the filename unless that is the purpose of the application.

Demo a sync program and find that all the creation dates have changed to today!

[kps]

> My experience with metadata is that a lot of applications don't care about its integrity [...]

This has led me to formally maintaining significant metadata in the filename, for certain kinds of files; everything else gets lost or diverges. For instance, a book file might be named `Title [a=Jim Smith; isbn=9781234567890].pdf`.

[quesera]

I feel like you're probably kidding, but I kind of like this.

Maybe not psyched about the shell-interpreted brackets, semicolons, and spaces. But the idea is interesting!

[kps]

No, I'm serious. There's no portable filesystem metadata, and while a few kinds of media files have facilities for internal metadata (e.g. EXIF and ID3), most don't. A file name is the only non-content that is easy to keep associated with any kind of file.

The syntax is definitely an imperfect compromise, but most of the things I use this for have titles that frequently contain spaces (books, papers, music, etc.) so quoting would be necessary anyway, and I made myself a Python package to help with escaping and do other utility tasks like normalizing ISBNs.

[jabroni_salad]

that's a good idea, especially if you don't want to keep a database to manage your library. In the piracy side of things we just make sure to name files something that can be used to look it up in the database and get metadata from that.

Although I have to warn you that ISBNs are not a perfect guid and they sometimes get reissued. Good enough if you aren't hoarding the world I guess.

[Karellen]

A lot of filesystems don't store file creation dates. Posix only requires last modification date (which for directories, is the last time a file/subdirectory was added, removed, or renamed), last access date, and last status change date.

[justsomehnguy]

because it requires some additional actions when navigating

[jbverschoor]

Yeah, I've migrated to this + a 'process'-kind of folder structure. I'll have more duplicate data, but it saves my sanity