Is this still supported, active? No new Tag Release

[StatusCode404]

Hi All Is this project still supported or active?
There's been no new tag or release in 3 years?

[sanmai-NL]

@Cebtenzzre I see you're still updating this. Can you give a brief response about the future of this project, and perhaps about help you need?

[cebtenzzre]

I've been put in charge of this project since Chris (sahib) hasn't had the time for it. I've fixed a lot of bugs locally, but I guess I've been overwhelmed trying to make everything perfect, so I haven't pushed a lot of code. Sorry about that. rmlint is a really broken program once you dig into it, and some days I just don't know where to begin.

I just pushed some commits that I've already had time to check over, which I feel more confident in. There are hundreds more that I haven't decided whether to keep, and may not have written a proper description or tests for. Hopefully I can put more time into sorting that out soon.

And I think I've mentioned this elsewhere, but I'm ignoring the develop branch for now. It has more new features than bug fixes, and I think the existing code has enough problems as-is, so I'm working off of master for the time being.

[StatusCode404]

"...rmlint is a really broken program once you dig into it..."

Is the last tagged release stable for production use?

There's a whole website dedicated to the usage and learning "on how to use this tool". Is this safe to use?

[cebtenzzre]

Here's a short, probably incomplete list of some of the more critical issues I know about, in no particular order:

• Under certain circumstances, --xattr-write with --write-unfinished (or just plain --xattr) can create false positives, i.e. cause unique files to be deleted. This is the only serious bug I know about which I haven't written a fix for yet, but I have a plan.
• --keep-hardlinked has no effect with -D/--merge-directories.
• --see-symlinks, which is enabled by default, can falsely match a symlink with a file if the contents of the file matches the path the symlink points to. You can use -F/--no-followlinks to avoid this.
• Until 1ecfb60b9821daceeea771abee4cbe66e9276738 (not in any release), rmlint with glib >= 2.75.3 will deadlock or segfault when using --no-with-color, sending its output to a pipe, or using the GUI.
• Until 8e1107835c61400ebb7e8d7f30f28f32319f8801 (not in any release), rmlint is prone to false positives if using -q/--clamp-low or -Q/--clamp-top with --xattr-write.
• The implementation of --replay on master is missing checks or accurate logic for all but the most basic command-line options, so it may silently ignore some of them, or do the wrong thing. develop has a better implementation that leverages the main filtering/postprocessing code instead, although I haven't tested it thoroughly.
• There is an assertion failure you can get when using -p/--paranoid mode under certain circumstances due to a data race while updating the file offset. Without assertions enabled (building without DEBUG=1) it may actually cause incorrect results, though I'm not certain. It's a hard bug to reproduce because of how rarely it occurs.
• There are quite a few crashes that you can run into in various ways, and a few deadlocks.

These are all edge cases, which hopefully people don't run into very often in practice, so I'm comfortable running rmlint on my own data. The usual disclaimer applies - check its output before running it, in case of obvious mistakes. Of course, I still intend to publish more fixes, and make a new release eventually.

[rpdelaney]

Just a thought since I'm not volunteering to do the work myself: it might be better to start over from scratch than to keep maintaining the big ball of mud. That always sounds daunting, because it is, but it might be less work in the long run than cleaning up a codebase that became messy over time.

Thanks for picking up the slack, whichever route you pick. rmlint does something that's needed, and however messy it is, nothing else does it better.

If you do decide to keep going, please don't wait for perfection before you cut new releases. All improvements are good, and the faster you get them out to the users, the better for everyone.

[sanmai-NL]

To me reimplementation in Rust would make sense, since it allows abstraction and low-level API usage. The former seems like a challenge given limited development time with C.

Rmlint is a great, unique tool and I would be willing to pay a bit for its development, since it covers such common tasks both at work and at home.

[someone-somenet-org]

Please do at least 1 release per year, even if you didn't do anything... that way people can see if a project was abandoned, or there is just nothing new, but its not dead.

[StatusCode404]

Well done @Cebtenzzre for tagging a new release and implementing a lot of fixes! :+1:

[StatusCode404]

Hi @cebtenzzre, Just checking if you are still supporting and continuing to maintain update rmlint?