I am testing locally compiled C-C TB under Debian GNU/linux.
It is a DEBUG build.
(No local patches except for strange GCC-10 compile time bug is applied. )
I am testing the behavior of error recovery in the face of I/O error (mostly write error) by storing my local messages in a folder mounted from a remote file system.
To simulate the I/O error, I pulled the plug and caused the timeout of File I/O operation to occur.

What I did:
In the Inbox, there were about a hundred plus small messages.
I selected them all to move them to Trash folder.
For that, I hit [delete] button.
As soon as, I hit the delete button (maybe a second or two later), I pulled the plug from the remote CIFS server so that the I/O operation would timeout and error is returned.

• TB responded with an error dialog.s
  (This was when the first screen dump attachment was created.)
  I restored the plug to remote CIFS server before hitting OK there.

I hit the OK button, and the dialog disappeared.

However, something went wrong. If I visited the Input folder, the messages were shown.
But if I tried to show the Trash folder by moving the cursor and click the Trash folder, the mouse cursor became a spinning icon and
nothing proceed. I could not access and show the Trash folder.

• Eventually, I figured that by compacting trash folder, this spinning icon is no longer shown.

Please recall that I tried to delete the messages from Inbox, but it was prematurely terminated or stopped in mid way. (I think the latter seemed to happen because by this time, I realize that somehow the messages from the Inbox were moved to Trash folder. I suspect this move has occurred after the compaction finished so it seemed that this "delete" operation interrupted by an I/O error was remembered by TB and as soon as I/O error no longer occurred and the "lock" condition of Trash folder (pure guess) disappeared, the DELETE operation occurred automatically.

Now, I tried to move the messages in trash folder to Inbox in order to continue test.
This is when TB said "The operation failed because another operation is using the folder.
Please wait for the operation to finish and then try again."
The folder in question seems to be Inbox. (See the 2nd attachment. The dialog message says "Error - Inbox on mtest2@locahost".

So this seems to suggest that the Trash folder was in strange state (note the spinning icon), and then after a while, the Inbox was put into a locked state, locked for a pending i/O operation.

Simulated I/O errors by the unplugging/plugging of remote CIFS server can
cause many types of errors the timing of which was not defined in detail
and co-related with TB's logic flow very well.
I/O errors during successive tests may cause TB to experience the error at
different code lines and so very difficult to produce.

At least, I know there is something wrong during the moving of messages to
Trash folder using "delete:".
This has been re-produced at least once.

It is hard to see what is going on.

I think I recreate the Inbox folder from scratch and fill it with messages with unique subject line for
later analysis, and test this scenario again.

One thing I noticed.
I thought it might be related to a semaphore held by TB for one of the folders (Inbox, Trash, or BOTH?) that was not released during error recovery operation.
So I quit TB while the mouse cursor began rotating when I clicked on Trash holder, hoping that the held semaphore would no longer be an issue
in a newly started TB.
A surprise. When I restarted TB, the mouse cursor was again a rotating icon when I clicked on the Trash holder (until I somehow cleared it by compactifying. Yes, I tried many things to see how I could proceed).
So, whatever the property of Trash folder that caused the rotating icon remained across stop/restarting TB. It could be an explicit flag in the database file, or it could be messed up database file, etc.

Folders can indeed get "locked" by incomplete operations. For example what happened bug 458570.

Perhaps folder operation code should be audited, and be protected by calling a folder function that doesn't allow failed transports from affecting the target folder?

(In reply to Wayne Mery (:wsmwk) from comment #3)

Folders can indeed get "locked" by incomplete operations. For example what happened bug 458570.

Perhaps folder operation code should be audited, and be protected by calling a folder function that doesn't allow failed transports from affecting the target folder?

Something along the line suggested should be done eventually, I think.
What surprised me is that this locking status somehow is retained QUIT/RESTART of TB.
I thought it was going to disappear with QUIT/RESTART. So there must be a database change or lock file left around.
(I suspect some runtime lock may be also involved.)