Metadata support

[grumphus]

Greetings and congratulations on your release!

I've been searching high and low for a decent and simple file organizer. The problem is almost all of them lack metadata support. (i.e. move an mp4 video file if Artist = xyz). Easy File Organizer by Qiplex is only app I know that supports it but the interface is a little clunky. If a lightweight solution can accomplish this, that would be awesome.

Cheers and more power to your software.

[hsr88]

Thanks for the kind words! This is a really compelling use case - sorting by metadata (EXIF, ID3, video tags) instead of just filename/extension would unlock a whole new level of organization.

You're right that most organizers skip this entirely. Adding metadata conditions to rules (e.g. Artist = "xyz" or Year > 2020) is definitely going on the roadmap.

Implementation-wise, I'd probably start with:

EXIF for images (kamadak-exif)
ID3 / Lofty for audio
MP4 metadata for video
PDF / DOCX document properties
Then expose those fields as rule conditions alongside the existing extension/regex filters.

No ETA yet, but I'll update this issue once there's a branch to test. Thanks for the suggestion! 🙏

[grumphus]

Great implementation and thanks for adding it to your roadmap. All the best! 🙏

[simonlpaige]

This is a solid feature request, but I'd suggest a few concrete design considerations before implementation:

1. Performance impact is non-trivial. Metadata extraction requires opening and parsing each file. For a tool targeting ~5MB RAM and silent background operation, scanning a Downloads folder with hundreds of files on every change event could spike CPU usage noticeably. Consider caching extracted metadata per file (using inode/mtime as cache key) and only re-extracting when the file changes.

2. The rule syntax needs careful scoping. The current rules are extension → folder. Metadata rules would need something like condition: (field, operator, value) → action. For example: (exif.DateTimeOriginal, before, "2024-01-01") → Archive/Old Photos. A good reference is how Apple's Shortcuts app structures file conditions.

3. Consider limiting metadata sources initially. EXIF for images and ID3 for audio are the most common asks. Video metadata (QuickTime keys, Matroska tags) varies wildly across containers and codecs—you'll want a library like symphonia or ffmpeg-next rather than rolling your own parser.

4. Test with edge cases: Unicode metadata (Japanese artist names), corrupt files, files with zero-byte metadata fields, and symlinks. These crash most naive implementations.

If you do proceed, rexiv2 (GObject-based) or kamadak-exif (pure Rust) are solid starting points for image metadata without pulling in system libraries.

[hsr88]

This is incredibly helpful, thank you for the detailed breakdown! 💯

You're absolutely right on all points:

Performance - naive metadata extraction on every file change would murder the CPU. Caching by (inode, mtime) is exactly what I had in mind.

Rule syntax -the current extension - folder is too simple. I like the (field, operator, value) - action idea. I'll probably prototype this as an advanced rule type alongside the existing simple rules so users don't have to learn the new syntax for basic stuff.

Limiting scope - EXIF for images and ID3 for audio first. Video metadata is a rabbit hole (QuickTime keys, Matroska tags, container vs codec tags…). I'll skip video for the first iteration.

Edge cases - corrupt files and zero-byte metadata fields are exactly the things that would crash a naive implementation. Defensive parsing + Option everywhere.

Plan: start a branch this week with kamadak-exif (pure Rust, no system deps) + lofty for ID3. I'll ping you when there's a test build.

Thanks again - this is exactly the kind of feedback that keeps the project from shipping a half-baked feature.