Beta Tag Order feature causes **data destruction** - suggestoin for clean solution included.

[ZebulonGlitch]

Describe the bug
If you drag and drop tags, Tagspaces hammers the crap out of my hard drive so bad that my storage target errors out and throws the file into a black hole. File gone. Glad i was using test data to try the feature...

To Reproduce
Drag and drop tags to set the order. The feature (with all due respect) is coded REALLY BADLY. The app is issuing HUDNREDS of file rename commands per second, and my computer starts to get seriously stressed out. You URGENTLY need to make it smart enough to just rename the file ONCE when the person lets go of the mouse button. Wow man. wtf.

Expected behavior
Drag and drop, it reorders tags. Woohoo.

Screenshots
n/a I would have to capture a video of my file explorer going ape-shit bananas when using this feature. It is terrifying, feature is off.

Desktop Application:
TagSpaces v5.0.5 from appimage
Linux Mint latest (Vanessa21 < Ubuntu Jammy) with Mate Desktop, fully up to date with Linux kernel 5.15.0-xx

Additional context
This is a REALLY important feature for the usability of the program. But you need to make it so that tag order is enforced based on the tag groups in the left side bar. I have reorganized those, and set the colors in an ideal way for myself, and the tags on the files should mirror this order so that I can audit my work and keep track of my progress visually.

SO give up on manual reordering, who wants to spend their lives doing that on a file by file basis? Just let us set the master order in the existing interface, and rock and roll. I can't imagine any users would be anything but happy if it functioned like that.

By constantly randomizing the tags it makes curating them needlessly difficult.

[uggrock]

Can you send me exact steps for the reproduction of this issue? What do you mean be the "Beta tag order" feature?

[uggrock]

I think i found it:

Well. this is a feature which is turned of by default and clearly marked as BETA... We simply do not have currently time to work on improving this functionality...

[ZebulonGlitch]

1. I put two windows side by side, a file explorer and Tagspaces looking at the same folder.
2. After a file disappeared with no trace while using the feature I tested Tagspaces Tag Reordering feature.
3. As you drag a tab around, the file explorer starts to go BONKERS. It is clearly executing countless file rename execution commands as you move your mouse around in Tagspaces. The file you are messing with starts to flicker at an incredible rate and jump all over the place as the operating system's file manager struggles to deal with it.

About 3 files got killed while testing. I'm quite sure Linux on its own could probably handle the hard drive abuse (even if Tagspace makes my SSD drive burn out prematurely from the abuse). But I use an encryption loopback device service for my personal photos and data. I'm quite sure this is a level of hard drive torture those developers never imagined. How could someone ever rename a file hundreds of times a second? Well now we know. I suspect the stress has exposed some overflow edge case issue that causes it to orphan or malform the underlying encrypted file. But no application should attempt such high frequency disk manipulations, Not all file systems were designed for it.

Should be fairly trivial for you to modify your execution loop during the drag and drop action so that it awaits a click release event before it executes the filename change. (Rather than on every pixel or mouse movement or at some high frequency clock rate.)