In yesteryear I used to do a bit of local photo management (but now that's done in google photos for the most part) and a bit of local music management (but that's spotify/youtube nowadays).
I would organize things differently but I've always been unsatisfied with having to reify some arbitrary subset of metadata about each file into a directory structure. It might seem reasonable to have photos in directories by YYYY/MM/DD but sometimes I want all photos that were taken in a particular location or that have a certain person in them.
I have had no fewer than four aborted attempts to start using camlistore^W perkeep. For some reason it just doesn't stick and I end up going back to the "... everything else" directory. The bit that always gets me is the interface between the object storage world and the posix world (where all my apps / editors live).
Internally, google has a really generic File API that abstracts over a plethora of internal storage systems. Public examples of those storage systems include things like GFS and Chubby (though Chubby support got removed IIRC because enough people didn't understand that they shoudn't use it as a generic storage system -- imagine FUSE-mounting a zookeeper subfolder as your ~/Downloads directory)). So if you're writing internal code, you just get this interface to access "file"s in a mostly-implementation-agnostic way. I don't know how many internal projects use regular POSIX files/directories, but it's probably fewer than you'd think.
For better or for worse, the open source community will never rally around a "file" interface that isn't POSIX-ish (directories and files), at least not on the desktop. A while back I got excited about filepicker.io (apparently rebranded as filestack since the last time I looked at it), because I'd love for there to be some layer (that isn't defined by Apple/Google), pluggable / extensible, that would allow me to organize files in a way that makes sense to me.
YYYY/MM/DD or even YYYY/MM definitely tends to be too granular for photos in my experience, but I've been dumping the recent year's photos / videos into a YYYY directory every January (which takes seconds to do), and it's been great. Gives me a fresh new directory for all the new media for the year, without directory fatigue when looking for older photos. I also clear out the photos / videos on my phone at the same time for the same reason.
That said, google photos is where I go to search my photos. I'd love something self-hosted, but I don't care enough to weigh options and implement something, and I especially don't care enough to build my own.
Google's File API sounds really interesting. I personally want a tag-based filesystem that can _look_ and even have interactions like directories and files, but works like a graph. There was a great discussion about that sort of filesystem in this thread: https://news.ycombinator.com/item?id=16763235
You should try PhotoStructure. Self-hosted, runs on desktop or headless or docker, and auto organizes your photos and videos into datestamped directories using whatever pattern you want.
Thank you for the recommendation. Looking at my Downloads folder, it seems I tried it out about 6 months ago, very shortly after my son arrived. I imagine that may be why I never gave it much of a chance. I look forward to revisiting it.
I would organize things differently but I've always been unsatisfied with having to reify some arbitrary subset of metadata about each file into a directory structure. It might seem reasonable to have photos in directories by YYYY/MM/DD but sometimes I want all photos that were taken in a particular location or that have a certain person in them.
I have had no fewer than four aborted attempts to start using camlistore^W perkeep. For some reason it just doesn't stick and I end up going back to the "... everything else" directory. The bit that always gets me is the interface between the object storage world and the posix world (where all my apps / editors live).
Internally, google has a really generic File API that abstracts over a plethora of internal storage systems. Public examples of those storage systems include things like GFS and Chubby (though Chubby support got removed IIRC because enough people didn't understand that they shoudn't use it as a generic storage system -- imagine FUSE-mounting a zookeeper subfolder as your ~/Downloads directory)). So if you're writing internal code, you just get this interface to access "file"s in a mostly-implementation-agnostic way. I don't know how many internal projects use regular POSIX files/directories, but it's probably fewer than you'd think.
For better or for worse, the open source community will never rally around a "file" interface that isn't POSIX-ish (directories and files), at least not on the desktop. A while back I got excited about filepicker.io (apparently rebranded as filestack since the last time I looked at it), because I'd love for there to be some layer (that isn't defined by Apple/Google), pluggable / extensible, that would allow me to organize files in a way that makes sense to me.