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: Delete {s} NORECYCLE SKIPNOTEMPTY FORCE QUIET
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.
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?
What about Delete {s} NORECYCLE SKIPNOTEMPTY FORCE QUIET
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).
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:
MoveToParent
Delete {s} FORCE QUIET
Or look at some of the other suggestions in the existing threads that Leo mentioned.
