I used Thaura Work to develop this simple tool that helps maintain file archives by enforcing file naming standards. The tool doesn’t do it directly, but helps you create simple scripts to enforce these rules.
To use it, download these two files, and then install the whl file using pipx.
These are pure Thaura Work code. I haven’t read it over.
Here are commands to use on these archives:
# to extract the documentation website
unzip fslint-site.zip
# to install pipx on debian
sudo apt install pipx
# to install the wheel file
pipx install fslint-0.0.0-py3-none-any.whl These new commands will be available to you:
fslint
fix_android_live
fix_android_photo
fix_android_screenshot
fix_android_video
fix_eu_ddmmyy
fix_iphone
fix_kodak_scans
fix_linux_screenshot
fix_mobizen
fix_snapchat
fix_taiji_yymmdd
fix_usa_mmddyy
Details are in the docs. Basically, fslint reports on files that don’t match the features specified in the options. I used a naming convention of “YYYY-MM-DD description.ext”.
The fix_* commands will fix some filenames by extracting the parts, and prefixing the filename with the date.
Here’s an example of how to use fslint in a script:
# Year folders must have a date prefix
fslint --isfolder --dateprefix ./Photos/
# Event folders inside any year must have a date prefix
fslint --isfolder --dateprefix ./Photos/*/
# Files inside event folders must be jpg, mp4, mov, or png
fslint --isfile --isext jpg ./Photos/*/*/
fslint --isfile --isext mp4 ./Photos/*/*/
fslint --isfile --isext mov ./Photos/*/*/
fslint --isfile --isext png ./Photos/*/*/Just like that, you can enforce some discipline on your archives.
Here’s the program help:
usage: fslint [-h] [--version] [--isfolder] [--isfile] [--dateprefix] [--pattern PATTERN] [--isext ISEXT] directory
Check that files in a folder conform to naming conventions.
positional arguments:
directory directory to scan
options:
-h, --help show this help message and exit
--version show program's version number and exit
--isfolder apply filters only to folders
--isfile apply filters only to files (skip folders)
--dateprefix require a date prefix like 2026, 2026-04, or 2026-04-01
--pattern PATTERN require filenames to match a glob pattern (e.g., "IMG_*", "[0-9]*")
--isext ISEXT only check files with the given extension (e.g., jpg, mp4, md)
Code language: HTTP (http)
venv
I used venv and makeapp. I wanted to see how well Thaura Work handled something that was made from a scaffold. The end product is above and it took a 3-5 hours.
The only real snag I had was how Thaura Work interacts with the virtual env. I’m not sure how Thaura works, but it seems to cause problems with venv, and when it hits error messages, it tries to fix it. It messed up the venv, but eventually figured out how to run the python code.
Later on, I repaired the files manually, while creating the whl file, but these fixes were just a big guessing game for me.
Obsidian
I made the work directory into an Obsidian vault. This is for reading and writing MD files.
Development Cycle
I started out writing a README file, giving an overview of how the tool worked. I told it to produce code, and then a directory of folders and files with names.
Then, I edited the names, by hand, to produce some good data and some bad data. I had Thaura read the names, and use the tool against the data. It failed, so it fixed the problems.
Then, I told it to create a bash script, create_testfs.sh, to build the sample data directory.
(Create directories first, with the LLM, alter them, then make a script to create them. That saved me the headache of writing a long prompt about what I wanted the script for.)
Then I brought in some files from my photo archives, with various names. I also downloaded a bunch of photos and other files from Google Photos.
I told Thaura to tell me what kinds of files these were, and then had it create the fix_* scripts to rename these files.
(I didn’t want “fixing code” inside the auditing tool, because I didn’t want to risk having any disk writes or file renaming code inside there.)
I repeated this process several times, running the code against both good and bad file names, and finding new files, identifying where they were from, and producing a fix_* script for that.
Sometimes, I’d tell Thaura to update the docs and create_testfs.sh script.
Sometimes, the process got weird, with date formats like “31-Jan-2026” and “2026-Jan-31”, and “2026-report.txt” and “2026-05-report.txt”.
The development cycle was extremely interactive, and reminiscent of programming in Basic in the 1980s, or writing shell scripts.
Here’s a portion of create_testfs.sh:
# a portion of the create_testfs.sh
set -euo pipefail
TARGET="${1:-testfs}"
rm -rf "$TARGET"
mkdir -p "$TARGET"
# --- Valid entries ---
mkdir -p "$TARGET/2026-01-24" # full date
mkdir -p "$TARGET/2026-02" # year-month
mkdir -p "$TARGET/2026-03-15 Description" # full date with space + description
mkdir -p "$TARGET/2026-05" # year-month
mkdir -p "$TARGET/2026-06 Selfies" # year-month with description
mkdir -p "$TARGET/2026-07" # year-month
mkdir -p "$TARGET/2026" # year only
touch "$TARGET/2026-report.txt" # year only with suffix
touch "$TARGET/2026-12-report.txt" # year-month with suffixDocumentation
Through this process, Thaura produced docs, updating the README, creating a HOWTO that’s now in the docs in the ZIP file, and even saving out a progress report.
This process, of writing docs seems to help Thaura, but I’m not sure how. They also give me a peek into what it’s doing.
It helps to have these docs in MD format, and in the work directory, so new chat sessions can pull in an overview of the project.
Results?
I thought the experience was pretty good.
I don’t know what the code quality is like, because I haven’t read it yet.
I forgot so much about venv, packages, etc. The Python ecosystem is complex.
Exporting the work to the WHL file was a pain in the ass. It makes me miss simple scripts that run anywhere, don’t require installation, etc.
I’ll try making other types of projects.