How to force windows to respect the rmdir command in my button?

So if I'm in a subfolder that I want to get rid of, I press the following button.

@set ChildPath={sourcepath$|noterm}
@runmode hide
Copy MOVE * TO ..
Go ..
rmdir {$ChildPath}

The contents of the subfolder always MOVE one level up in the hierarchy.
And the GO command always works.
But when the computer is also busy doing something else, like copying another large file,
the RMDIR command is just ignored and the now-empty subfolder remains.

How to force the removal?
Are the commands behaving asynchronously, which would make a -f flag too dangerous?

No need to use the DOS rmdir these days. You can get the same thing using internal commands, removing the need to use MS-DOS Batch mode and @runmode hide.

@set ChildPath={sourcepath$|noterm}
Copy MOVE * TO ..
Go ..

You may find that works better.

Corrected last line in the command above.

I'll try this out for a few days. Thanks!

aggh - it's still occasionally acting as if the DELETE is trying to happen before the MOVE is complete, thus triggering the FAILNOTEMPTY condition...

but at least my button code is cleaner...

There might be something else still locking the directory. (Virus scanner, thumbnail generation, etc. are likely candidates, if nothing had been actively using it or launched while that folder was the current directory.)

Sometimes moving the files up to the parent can take up to 5 seconds, especially when the same drive is busy with another copy operation.

There's not a built-in while loop I could run that would only DELETE once the folder is empty, is there?

If not I could do it all async in node...

That command would be synchronous already. The Delete command won't run until the previous command is finished.

interesting experiment

I removed the QUIET flag so I would get the delete confirmation box,

I started a separate 5 gig file copying to my current drive just to slow things down,

Then I used the button on a folder full of files.
The move-to-parent happened (taking about 2 seconds of course)
but the delete confirmation never happened! - so delete is bailing out when there is a slow move, it seems,

I understand if it might be too dangerous to make the delete more forceful.

Try removing the FAILNOTEMPTY as well. (But don't actually delete the folder, just see if you're asked to confirm.) The folder may not be empty, causing the delete to be skipped.

Is a non-Windows NAS involved here or a local drive?

I removed FAILNOTEMPTY and the confirmation (and DELETE) was still completely skipped every time the MOVE took more than a split second.

This is a NTFS formatted local drive plugged up right inside the chassis - SATA

Try removing any @keydown stuff as well, in case that's causing the line to be skipped.

removed @keydown and same behavior - delete is skipped when the move takes too long

What's the full command you are using now?

Please post a screenshot of the button editor so we can see all the settings as well as the command.

I recently switched the Function: type from MS-DOS to Standard Function (Opus or external). That may have fixed it!

edit: it did not fix. The Delete command still occasionally bails out FAILNOTEMPTY because it seems to be running before the copy MOVE above it is complete...

Not huge priority though. Don't even know if it is possible to fix...