Copy MOVE TO is copying and deleting instead of moving

I use this command for a button to move the contents of the selected folder to its parent folder and to delete the folder afterwards.

Copy MOVE TO={filepath$|..\..} 
Delete {s} FORCE QUIET

This works fine but I noticed that instead of moving the files, the files are first copied to the parent and than deleted from the subfolder.
The first entry in the Undo list is the Move of the files, the second entry is the Deletion of the files. I expect it the other way around, because how can it move files when they're deleted?

Anyway, this copy/move and delete action takes longer than a regular move.
Why does this two step process happen? What's wrong with my command?

To prevent accidental removal of a folder that isn't empty because the copy action failed somehow, I used this Delete command:
But when I use this, it's not quiet anymore and ask if I really want to delete the folder.
So I skipped the check. Something that I would rather not have.

I would expect Copy MOVE to be quite fast when the files stay on one drive. So maybe Rename works better in your case. Try

Rename {sourcepath}* TO ..\* WHENEXISTS=ask

Adjust WHENEXISTS to your needs.

That should just move the files by renaming if the source and destination are detected as being on thr same drive.

Is there anything unusual about the folder you're moving things around below? Any junctions or softlinks or libraries involved?

No, it happens on all drives, all folders I tested. No special things like junctions or softlinks. No use of labels.

The problem even occurs with a new Test folder on C:, containing a sub subfolder with empty txt files.
I start with the situation in before.png.

I select all files and press my button.
While moving using my command the screen of DO flickers.
The result is fine as you can see in after.png.
The undo pane shows what happened.

The undo log is probably because of the delete command

Even if Copy MOVE moves files via copy-then-delete, it will still appear as a single move operation in the undo log and not the separate copy and move steps.

I think the buttons & toolbars area has some threads with better ways of moving everything up and deleting the old folder (if empty), by the way

The line with Delete in de undo log has indeed to do with the deletion of the subfolder. When I remove the delete command, the Delete action is not written to the log.
Though, it is weird and confusing that the log says Deleted 23 items while it's just one sub folder, so 1 item.

I will take a look in the buttons area. But if a simple DO command can't do the trick in a proper way, why would a complicated button or script do?

They aren't complicated, just slightly different.

What about
not being quiet when the folder is empty?

Has this something to do with the deletion of the folder on its own?

I can see this happening in a progress window where it's deleting files one by one. (That explains the number of deletions in the Undo pane.)
The progress information alternates between the sub folder name and each file name.
But the files already have been moved to the parent folder (as I can see in the destination pane I opened to view what's happening).

deleting%201 deleting%202

So you can direct me to 'better' scripts and buttons but obviously something's wrong here. Might be best to fix this.

The files are being moved correctly. If you look at the file log rather than the undo log (with logging set to "maximum" in Preferences / File Operations / Logging) you can see what's actually happening.

First, each file is moved to the parent folder. After that, Opus tries to delete the source folder 23 times.

Unfortunately this is just how the command parser works. As soon as you have a command line that passes one filename at a time (as you are doing with the use of the {filepath$} code, the entire function is run for each selected file.

The easiest solution is to use the @runonce modifier to make sure the Delete command is only run once:

Copy MOVE TO={filepath$|..\..}
@runonce:Delete {s} FORCE QUIET

Alternatively, you could move the Copy command into a user command. For example, you could have a user command called MoveToParent that ran this command:

Copy MOVE TO={filepath$|..\..}

Then your button would become:

Delete {s} FORCE QUIET

Or look at some of the other suggestions in the existing threads that Leo mentioned.