# szyszka: a fast bulk file renamer built from rule chains

> Szyszka renames files in bulk by applying a chain of rules you can combine freely, and it is built for the case where the naive tools give up: hundreds of thousands of files, and folders alongside files. It is a small Rust application with a graphical interface, and it is distributed as binaries, a snap, a crate and a Gentoo package.

**qarmin/szyszka** — Szyszka is fast and powerful file renamer

- Repository: https://github.com/qarmin/szyszka
- Stars: 987 · Forks: 37
- Language: Rust
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/qarmin-szyszka

## The problem the alternatives solve badly

The readme explains the project's origin in a way that is more useful than a feature list.

The author tried a number of other applications and they did not suit their needs, and the alternatives section names three of them with the specific complaint about each. One is quite fast and built into the file manager, but it hangs when used with more than ten thousand files and cannot be used with files or folders from different directories. Another is the one Szyszka bases a lot of its features on, but it cannot add items recursively or rename folders. The third is a simple and good looking application that is quite powerful, but slow, and which the author had trouble installing.

Those three complaints are the specification for the project. Recursion and mixed directory trees are the hard cases, and the scale of a hundred thousand records is the third.

The feature list follows from that. Great performance. Availability for Linux, Mac and Windows. A graphical interface. Multiple rules which can be freely combined. The ability to save rules for later use. The ability to edit and reorder both the rules and the results. And the claim that it can handle even hundreds of thousands of records.

That last one is the differentiator, and it is also the hardest to promise. A bulk renamer that streams a directory listing, applies the rules and updates a preview list as it goes has to avoid building a widget per file, which is why the dependency list later on includes a parallel processing library and a directory walker.

## The rules, and the fact that they compose

The rule types are listed, and the set is small enough to learn in a minute.

There is replace text, trim text, add text, add numbers, purge text, and change letters to upper or lower case. There is also custom rules, which is the escape hatch for anything the built-in set does not cover.

The word that matters in the feature list is combined. A single replace is a find and replace, which every file manager can do. A chain is a pipeline, so you can trim a prefix, add a numbered suffix, and fold the case in one pass, and the order matters and you can reorder it.

Two supporting features make that practical. Rules can be saved for reuse, so the chain that produced last month's export can be applied to this month's. And both the rules and the results can be edited and reordered before anything touches the disk, which is the safety mechanism. A bulk renamer is only trustworthy if you can see what it is about to do and change your mind, and an editable preview is the difference between a tool you trust on a directory of 200,000 files and one you do not.

The feature list also says the tool can handle even hundreds of thousands of records, and given that the results are editable, the interface has to be lazy in some way, because you cannot build two hundred thousand editable rows.

## The readme and the manifest disagree about the toolkit

Here is a detail an evaluator should notice, because it changes the installation instructions.

The readme says the graphical interface is created with GTK 4, and the requirements section says you need GTK 4.6 installed, with a package install command for Linux and a homebrew set for macOS, which the readme marks as not tested. The Windows section says the released archive contains all dependencies and works out of the box on Windows 10 and later.

The package manifest says something different. The description field calls it a fast, powerful and easy to use file renamer, and adds the words Slint port. The interface dependency is the Slint toolkit at version 1.13, configured with the compatibility and standard library features, the winit backend and the femtovg renderer, and the build depends on the Slint build helper.

So the project has moved from GTK to Slint, and the readme has not been updated to match. That is a small thing and a normal thing, and it has a practical consequence: a user following the readme on Linux will install a toolkit the current build does not need, and a user following the manifest will not install the one the readme tells them to.

The rest of the manifest tells you about the application's internals. There is a parallel processing library and a directory walker, which is the answer to the hundred thousand records claim. There is a library for human readable file sizes, a slug generator, a natural ordering library, which is what makes a numbered file list sort sensibly rather than alphabetically, a crate for opening files, one for the clipboard, one for native file dialogs, and a set of logging crates that include rotating log files and panics logged with a backtrace.

The internationalisation stack is also there, with a fluent based embedding library, the file format extension, and the system and desktop requester features, which matches the readme pointing at a translation platform for contributions.

## Five ways to install it, and one that is a placeholder

The installation section covers the usual platforms, and it is worth reading the order because it goes from the easiest to the most involved.

Pre-compiled binaries are at the repository's releases page, and on Windows the archive contains all the dependencies.

```shell
sudo apt install libgtk-4-bin
```

The snap is the one with a configuration step, because the sandbox has to be allowed to see removable media before it can rename files on an external drive.

```shell
snap install szyszka
sudo snap connect szyszka:removable-media # Allows to see files on external devices
```

The Flatpak entry is a single word, a to-do marker, which is an honest thing to see in a readme and a reminder that the packaging story is not finished.

The Cargo install is the one for people who already build Rust things.

```shell
cargo install szyszka
```

And there is a Gentoo package in the GURU overlay.

```shell
emerge -av gui-apps/szyszka
```

Five routes, of which one is a placeholder. That is a decent distribution profile for a small utility, and the fact that the crate is on the registry means the tool is installable on a platform nobody has packaged it for, as long as the toolkit dependency resolves.

## The dependency list explains the design

The manifest is a compact description of how the program works, and a few entries are worth pointing out.

The parallel processing library and the directory walker together are how the application handles a very large directory without freezing. The natural ordering library is the one that makes an enumerated list of renamed files appear in the order a human expects rather than the order the filesystem returns, which is the kind of detail that separates a tool people keep from a tool they try once.

The slug library and the human size formatter are there for the two tasks that every renamer needs and that are easy to get subtly wrong, turning text into a filename-safe token, and showing a size in a form a person can read at a glance.

The regex library is the custom rules engine, and the fact that it is a dependency rather than a hand written matcher tells you the custom rules are expressions, which is a far more capable design than a fixed set of dialogs.

Then there are the small ones that make an application feel finished. A library to open a file in the default application, one for the clipboard, so you can copy a path, and one for native file dialogs, because a file renamer without a proper folder picker is a file renamer you cannot use on a large tree.

The logging stack is the most deliberate choice. Rotating log files, a logger with a nice console format, and a crate that turns a panic into a log entry with a backtrace. For a program whose whole job is to modify files in bulk, being able to read back what happened afterwards is not a luxury, and a panic that leaves a log entry instead of a silent abort is what you want at three in the morning.

## The project, its name and its conventions

A few closing details.

The name is explained in the readme, and the explanation is a small essay. Szyszka is the Polish word for pinecone, and the author asks why such a strange name, and answers that while you would probably not remember another name like Rename Files Ultra, you would probably also not remember this one, but when you hear it you will instantly think of the app.

The project is MIT licensed, and the source is Rust with a minimum version requirement of a recent compiler and the 2021 edition of the language. The manifest also carries a list of clippy lints that are switched off, each with a reason. Some are legitimate cases, some exist because a different name is not always possible, some are there because a function genuinely needs many arguments, and one is allowed because the code indexes and unwraps where the author believes it is safe. Reading that list tells you a lot about how the author works.

The justfile is the file that made me look twice. It has the usual recipes, and then a fix recipe that runs a search across the Rust, interface, Markdown and translation files for three different dash characters and replaces them with a plain hyphen, before running the formatter and the linter with automatic fixes. So the project has a house rule about dashes, enforced by a command you can run, in a codebase that has both a documentation set and a translation set to keep consistent.

The readme also asks for contributions, and specifically reminds people that when they create or modify a rule they must update or add tests, and points at a translation platform for the localisation work.

On the release history, the versions are 1.0.0 in May 2021, 2.0.0 in July of that year and 3.0.0 in May 2023, with the last push on 2026-06-06 and the repository not archived. So the code is still being touched, and the major version three is the one that came with the toolkit change.

## Conclusion

Szyszka suits somebody with a directory of hundreds of thousands of badly named files, or a tree mixing files and folders, because that is the case the alternatives in the readme describe as broken. It is a poor fit if you need scripted, unattended renaming, since it is a graphical tool, and it is a poor fit if you want a stable interface, because the toolkit underneath has changed and the readme has not caught up. Before you install it, read the manifest rather than the readme for the toolkit requirements, since the two disagree, and check that your distribution has the runtime library the current build needs.

## FAQ

### What does szyszka do?

It is a bulk file renamer that applies a chain of rules you can combine freely, including replacing text, trimming text, adding text, adding numbers, purging text, changing letter case and custom rules. You can save rule sets for reuse, and both the rules and the results can be edited and reordered before anything is renamed on disk.

### Why did the author write szyszka instead of using another renamer?

Because the alternatives did not fit. The readme says one of them hangs with more than ten thousand files and cannot mix files and folders from different directories, another cannot add items recursively or rename folders, and the third is slow and hard to install. Szyszka handles hundreds of thousands of records and works across directories.

### How do I install szyszka on Linux?

Pre-compiled binaries are published with the releases, there is a snap, the crate is on the Cargo registry for a cargo install, and Gentoo users can install it from the GURU overlay. The readme's Linux requirements section asks for a GTK library, while the package manifest describes the current build as a port to the Slint toolkit, so the manifest is the more reliable source.

### What are the custom rules in szyszka based on?

On regular expressions, since the manifest carries a regex library as a runtime dependency, which is what makes the custom rules far more capable than a fixed set of dialogs. The tool also depends on a natural ordering library so that a numbered list of results appears in the order a person expects rather than the order the filesystem returned.

## Sources

- [Issues](https://github.com/qarmin/szyszka/issues)
- [License: MIT](https://github.com/qarmin/szyszka/blob/master/LICENSE)
- [qarmin/szyszka on GitHub](https://github.com/qarmin/szyszka)
- [README](https://github.com/qarmin/szyszka/blob/master/README.md)
- [Releases](https://github.com/qarmin/szyszka/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/qarmin-szyszka