[HN Gopher] TMSU: Command-line tool for applying tags and viewin...
___________________________________________________________________
TMSU: Command-line tool for applying tags and viewing virtual
tagged filesystem
Author : walterbell
Score : 61 points
Date : 2025-01-23 16:29 UTC (6 hours ago)
(HTM) web link (tmsu.org)
(TXT) w3m dump (tmsu.org)
| pvg wrote:
| Discussions in 2014 and 2016
|
| https://news.ycombinator.com/item?id=8738869
|
| https://news.ycombinator.com/item?id=11660492
| lemonwaterlime wrote:
| See also:
|
| - "Designing better file organization around tags not
| hierarchies" [1]
|
| - `tag` - a macOS version of `tmsu` that uses the system tags
| (xattr-based if I recall) [2]
|
| [1] https://www.nayuki.io/page/designing-better-file-
| organizatio...
|
| [2] https://github.com/jdberry/tag
| ecmm wrote:
| I also inadvertently implemented something similar as a zsh
| script [1] and as a simple rust CLI [2] a couple years ago.
|
| [1] https://github.com/xdoardo/zshelf
|
| [2] https://github.com/xdoardo/shelf
| Imustaskforhelp wrote:
| yea when I was looking for linux version I was finding tag
| again and again lol
| thebeardisred wrote:
| I was wondering why this wasn't using xattrs.
| NotPractical wrote:
| xattrs are great, and would the obvious solution for
| tags/metadata on Linux too, if the syscall API didn't delete
| them at every opportunity; programs must be explicitly told not
| to do that.
|
| https://wiki.archlinux.org/title/Extended_attributes
|
| That being said, it'd be cool to see a port of that CLI to
| Linux using user.xdg.tags. You can avoid deleting them if
| you're careful.
| Imustaskforhelp wrote:
| Yoo this is such a great idea , I once saw a video of a youtuber
| creating open source tag software and I don't know , I realized a
| frustration and I was also needing something like this once and I
| was installing this tag cli tool
|
| but this seems even better, this is why I am on hackernews
| teach wrote:
| I messed with TMSU back one of the previous times it was posted.
| It's very cool and works well but I just couldn't make myself go
| retroactively apply tags to terabytes of existing files.
|
| It almost feels like a personal categorization version of the "AI
| Bitter Lesson": people keep thinking that doing a bunch of manual
| taxonomy work is going to help them find files faster but
| eventually search catches up
| bityard wrote:
| My version of that is, "metadata curation is a fun hobby but
| search is king."
| walterbell wrote:
| Search and LLMs can make good use of accurately labelled
| data.
| sunrunner wrote:
| > retroactively apply tags to terabytes of existing files
|
| This has always felt like one of the primary issues with tag-
| based lookup over hierarchical. By the time you're knee deep
| with enough stuff that you realise tags would help, you've
| already accumulated too much to practically deal with.
|
| That and figuring out what the tags should be upfront and
| hoping you don't realise you need additional or different tags
| later on.
| walterbell wrote:
| CLI tools (find, grep, locate, tmsu) enable bulk changes to
| tags.
| londons_explore wrote:
| > people keep thinking that doing a bunch of manual taxonomy
| work is going to help them find files faster but eventually
| search catches up
|
| This. I spent many days cataloging, tagging, deduping and
| organising my photo and data files, programs, bookmarks, etc.
|
| And I've barely used any of those photos or data files since.
| The time invested totally wasn't well spent, and I should have
| just left everything called "DSC0000565.jpg".
| exe34 wrote:
| I really wanted this to exist about 15 years ago, but at the time
| didn't have the skills to make it happen. Nowadays though I'd
| want something that can sync across between Linux and Android at
| the very least. But I've gotten to comfortable with find and grep
| to bother.
| eviks wrote:
| Nice idea, all these type of databases should indeed support both
| hierarchies and tags for any decent organization, but no gui and
| no update tracking - unfortunately, that's way too limiting
| buildbot wrote:
| Something like this just for photos has been in the back of my
| mind forever - it would be really nice to have a virtual folder
| built from images where the exif data says you used X camera or
| took the photos on X date. This would be useful for editing
| applications that are not catalog based, just point them at the
| virtual folder and query the images you want to edit, and there
| they are.
|
| Edit - Someone mentioned befs but deleted their comment, it seems
| like it might sorta be supported in modern linux, possibly just
| read only though:
|
| https://github.com/torvalds/linux/tree/master/fs/befs
| IncreasePosts wrote:
| I'm sure one could whip together a FUSE filesystem like this
| very quickly. Here's something similar from 12 years ago:
| http://pisarenko.net/blog/2013/06/02/introducing-photofs-fus...
| buildbot wrote:
| For sure, just need the time and motivation :)
| walterbell wrote:
| Apple/Android devices could assist with offline image analysis
| and metadata generation,
| https://github.com/mazzzystar/Queryable
| groby_b wrote:
| If you mostly want to query and can live without the VFS,
| dogsheep[1] is your friend. It's a general tool to import lots
| of different data types into a personal sqlite instance, and
| dogsheep-photos[2] both extracts image metadata and uploads all
| the pics to S3 if you'd like.
|
| On my to-try list, there's also supertag[3], a tag-based
| filesystem that's mounted via FUSE
|
| [1] https://dogsheep.github.io/ [2]
| https://github.com/dogsheep/dogsheep-photos [3]
| https://amoffat.github.io/supertag/
| EvanAnderson wrote:
| I'm the guilty party who deleted the comment re: BeFS. I
| thought my analysis of the project was a little biting and,
| aside from mentioning BeFS, I didn't think my comment was
| adding much.
|
| I thought about photos and EXIF tags, too. Duplicating the data
| from the EXIF into another repository strikes me as a bad idea.
| That's why I was pining for BeFS.
|
| (I have a lot of crazy ideas about filesystems (arguably more
| like digital asset management systems) and data ingestion and
| export. Ideas kind of like the failed WinFS. Nothing will ever
| come of it because I don't have the skills or the time, but
| sometimes in fever dreams I imagine this stuff.)
| jrgaston wrote:
| Check out Lightroom.
| buildbot wrote:
| I have 41k photos in my Lightroom catalog, I've checked it
| out.
|
| That doesn't work when I want to use Capture One, Lightroom
| does not apply Phase One calibration profiles which makes it
| useless for them, or my own raw processor for Sinar digital
| backs.
|
| Recommending the most common digital photo DAM/editor is not
| really a helpful comment either. The number of people who
| know what exif is and don't know about Lightroom has to
| be...small.
| somat wrote:
| I still maintain that all it would take to add tags to the unix
| filesystem is to start calling "files" "tags"
|
| then use ln to add tags.
| dotancohen wrote:
| Wouldn't really help for the use cases that I can think up.
| $ ls -l # How grep for files with tag "foo"? $ find
| . -tag foo
| dddw wrote:
| Makes me think of tagspaces https://www.tagspaces.org/
| bityard wrote:
| I'll admit when I first saw this, I was put off by the idea of
| having a separate tool to do something that _should_ be baked
| into the filesystem. But honestly, this a pretty close to a very
| Unixy way of solving the problem. Have a separate (and
| importantly: optional) tool that does the job and does it well.
|
| Additionally, Linux _does_ support tagging files right in the
| filesystem via the user.xdg.tags xattr. Although it looks like
| Dolphin is one of the few userspace tools that knows about it.
| steffres wrote:
| I do this manually by appending `__t_tag`, where `t` is a
| category and `tag` the value.
|
| E.g. `__o_car`, where `o` means object, or `__p_supercode`, where
| `p` = project, `__t_ml`, where `t` = topic, ml = machine
| learning, etc.
|
| No dependencies, hardcoded into the files forever, and search is
| reasonably fast too (don't need it that often anyway).
| layer8 wrote:
| This reminds me a bit of the DESCRIBE command in 4DOS ca. 35
| years ago [0]. It was only a single text entry per file, but
| supported by many tools [1], including file managers. There was a
| proposal to extend the format to XMP properties [2].
|
| [0]
| https://archive.org/details/bitsavers_jpsoftware_65101374/pa...
|
| [1] https://4dos.info/4tools.htm#02
|
| [2] http://www.optimasc.com/products/fileid/4dos-descext.pdf
| quantadev wrote:
| The fact that some kind of tags or Key/Value storage as
| attributes on files, has been missing until 2025 (and still is)
| seems so bizarre to me. Our file systems have hardly changed
| since the 1960s. We get filename, timestamp, filesize, and that's
| about it. Pathetic.
|
| Imagine the opportunities if a folder structure could represent a
| "document" where each file represents a paragraph, or image,
| chunk of that document. We would be able to do 'block-based
| editors' (like content management systems, or Jupyter Notebooks)
| without having to have some large XML file holding everything.
|
| Even if we had simple "ordinal" (ordered position) for files that
| would open up endless opportunities for innovation in the 'block-
| editor' space, but sadly File Systems development has been frozen
| in place for decades.
___________________________________________________________________
(page generated 2025-01-23 23:01 UTC)