Create Folder while copy/move ? PLUS Delete (cont'd)

ref old (2005) thread Create Folder while copy/move?

Explaining how to create a drop menu:

Create FileNamed Folder to Move to ...
command: dopusrt /cmd Copy MOVE TO HERE CREATEFOLDER "{dlgstring|Specify folder-name to MOVE items to...: {d}|{d}}"

and
Create FileNamed Folder to Copy to....
command: dopusrt /cmd Copy TO HERE CREATEFOLDER "{dlgstring|Specify folder-name to COPY items to...: {d}|{d}}"

works perfectly.

After a move of files, sofar I have always deleted the empty folder separately.

If at all possible.., what to add to the code to have the empty folder deleted after files have been moved?

Note: folder_1 might have a subfolder_2, that may contain files. In that case the folder_1 is not empty and should not be deleted.

TIA

Not sure I understand...

When moving the folder's contents to a new folder, the sub-folders would be moved as well so it would always be empty afterwards.

When copying, instead of moving, it would never be empty afterwards (unless there was nothing in it).

Sorry for the confusion.

Following scenario may be of help:
Folder1
subfolder 1a
Folder2
subfolder2a
subfolder2b
sub-subfolder2c

when moving files from subfolder 1a to folder1 (drag them to that folder) or using the below move context menu option - when a new folder shd be created -
subfolder 1a is then empty and I should delete it manually afterwards

same as 2a->2, but not for folder2b to folder2 (because there is a subfolder attached to subfolder2b)

For one, two or half a dozen folders, well, manual delete is no problem, but when moving around a lot of files, it would be nice
when deletion of the empty leftover folder cud be deleted automatically.

Bad luck, if it is not possible though..

TIA

You can use the MS-DOS rmdir command to remove empty directories while leaving non-empty ones. Add this to the command and it should do what you want:

@runmode hide cmd /C rmdir {filepath$}

Thanks.

I now have:

Create New Folder to MOVE to...
dopusrt /cmd Copy MOVE TO HERE CREATEFOLDER "{dlgstring|Specify folder-name to MOVE items to...: {d}|{d}}"
@runmode hide
cmd /C rmdir {filepath$}

it moves the files, but I am afraid the folder is not deleted.
sorry.

Maybe {filepath$|..} instead, if you want the parent of the selected item deleted rather than the item itself (which I guess will be moved and not exist to be deleted anyway)?

I'm still not totally sure what the aim is here. :slight_smile:

Thanks. Regretfully it did not work. :frowning:

it now reads:

dopusrt /cmd Copy MOVE TO HERE CREATEFOLDER "{dlgstring|Specify folder-name to MOVE items to...: {d}|{d}}"
@runmode hide
cmd /C rmdir {filepath$|..}

my aim is to delete the empty folder after having moved the files in that folder to another location.
so, in the right window panel I select files, move them to another folder, then I have this empty folder.
Until now I delete that: click on the folder in the left window panel, hit del button, click ok to confirm.

But maybe what I am asking for isn't possible and I go on the way I did.
It would just be handy to avoid the extra handlings.

=

Remove the @runmode hide, and change the cmd /C to cmd /K

What does the window that pops up say?

Changed as per above.
Popup window says:
"The process cannot access the file because it is being used by another process"

and then followed by the
folderpath.

oh, by the way, I have enter exit each time after a file is moved, so in a separate small window there is a progress bar.
I moved 5 files, so 5x exit until the progress bar has completed, but the empty folder is not deleted.

I guess the command itself may be running with that folder as its current directory, which would block deleting the folder.

I still don't really understand how the command is being used. Could you post a screenshot showing the moment where you execute it (e.g. about to click on the toolbar button or menu item, after selecting the files/folders you'd normally select)? Maybe that'll make it clear in my head, and then make it obvious what's going wrong.

Well, this is the idea.

I have x files in folder x:\test\test1
I "move" them with name option to test (or whatever other location) giving them a new foldername
After the files are moved, the folder test1 has become null and void and actually shd be deleted.
For that I now need to click in the left window panel, click on subfolder test1, hit DEL button or RMB select and select delete, click ok.
These last few steps I wish to be automated, if possible..

Thanks!

This seems to work:

dopusrt /CMD Copy MOVE TO HERE CREATEFOLDER "{dlgstring|Specify folder-name to MOVE items to...: {d}|{d}}" dopusrt /CMD Go {d} @runmode hide cmd.exe /C cd .. && rmdir {s}

Hmm, looking at that, you could probably remove the dopusrt /CMD Go {d} line, but I've only tested with it in (and maybe it's useful anyway; shouldn't do any harm, either way).

If you're moving "all" the contents of the source folder - and then wanting to delete the source folder; wouldn't you just MOVE the source folder and give it a new name (i.e. do a "Move As" of the source folder itself - instead of the "contents" of the folder)?

[quote="leo"]Thanks!

This seems to work:

dopusrt /CMD Copy MOVE TO HERE CREATEFOLDER "{dlgstring|Specify folder-name to MOVE items to...: {d}|{d}}" dopusrt /CMD Go {d} @runmode hide cmd.exe /C cd .. && rmdir {s}

Hmm, looking at that, you could probably remove the dopusrt /CMD Go {d} line, but I've only tested with it in (and maybe it's useful anyway; shouldn't do any harm, either way).[/quote]

Thanks !!! a lot, it works fine...
(sorry for the delay, did not attend my pc one or two days).

This allows me to move files from a folder on partition X to a newly created folder on partition Y.

In the above scenario (2 partitions), Directory Opus'standard drag-and-drop leaves the files in the source folder, so I have to delete files/folders separately.
The standard built in move (drag-n-drop) of DO does not have a kind of an option to 'afterwards cleanup'' of the empty folder, regretfully.
I did submit a feature request to have this available as an option, but it remains to be seen (=fear it is doubtful) whether they will include into DO.
Seems to me that such an option is fairly logic: when moving files to another location why keeping an empty folder, some still want to keep the folder
(default behaviour), some, like me, would then tag 'cleanup empty folder after move' option :wink:

Timebeing the above is great.

Many thanks again!!

Hi Steje,
Thanks for your suggestion.
Am not sure, but I think one should have to move around a lot then, move the sourcefolder to subfolder xyz on partition X to go that partition, subfolder, rename, move back again,
take next folder, and so on.
It is no problem in case of moving just a few folders only, but in case of lots of files, folders, I guess this may take a lot of time of clicking and going back and forth?

Huh? That's got me very confused - the code seemed to me to do something like:

  • source is E:\test\test1
  • darg and drop menu to move all files in the source to a "new" folder in E:\test (the parent folder of the folder you're currently in)
  • delete the source E:\test\test1 folder

Isn't that the same as simply "renaming" your current directory without all of this button code, selecting and dropping files? Personally, I do this same thing with a <Shift+F2> hotkey (since it makes sense to me to use a varitaion on F2 inline rename) which run the command Copy MOVE {s|noterm} TO {s|..} AS {Rs|Specify new name for current folder|{s|nopath|noterm}}...

And for moving a slightly different scenario, when you're trying to move all files in a folder someplace else (but still delete the folder when you're done), all I'm saying is that instead of dragging all the files to a new folder, and then again have all of this button code running - why would you not just Go UP BACK, and then drag the entire (single) folder you were just in and simply do a 'Copy MOVE AS'? It will be a single operation with a single command that you provide the new name of the folder for.

Guess it doesn't really matter - if you can get some other more complicated way to work reliably for you - to each his own :slight_smile:.

Hi Steje, give it a try using Leo's code and nót entering a name when the popup is asking for it.
e.g. say you have 2 folders
x:\test\test1
x:\test\test2
select files in test2
then use leo's code and drag-drop them to test1, but.. when once the popup shows up, then just click on OK
you'll notice that the files are moved to test1 and test2 is deleted afterwards.

Actually this is what I have been looking for.

Right now, it is still prompting the user, am afraid this is unavoidable.

Maybe one day in future it will be in DO's options, something like:

When moving files
[X] Automatically delete empty sourcefolder
[_] Ask to delete empty sourcefolder

:smiley:

=

If you don't want the {dlgstring} question pop-up, just remove it.

I also just noticed there are some problems with quotes in the old buttons. (In one place it adds the quotes explicitly, without telling Opus not to add (extra) quotes if it thinks they are needed.)

Here's a fixed version of the old button:

@nofilenamequoting dopusrt /CMD Copy MOVE TO HERE CREATEFOLDER "{dlgstring|Specify folder-name to MOVE items to...: {d}|{d}}" @runmode hide cmd.exe /C cd .. && rmdir "{s}"

Here's a version of that with the question pop-up removed:

@nofilenamequoting dopusrt /CMD Copy MOVE TO HERE CREATEFOLDER "{d}" @runmode hide cmd.exe /C cd .. && rmdir "{s}"

Looking at this command some more, it's a little weird that it tells the copy command to move things "here" and then specifies a full, absolute path to the createfolder argument... There's surely a better way to do that... but, anyway, if it works, it works.

Thank you again!

Initially I gave it a number of tries myself with just {d} without quotes and without 'createfolder' parameter, wrongly assuming there was no folder to be created.. :confused:
Also I tried the

@runmode hide
cmd.exe /C cd .. && rmdir "{s}"

in combination with commands that have posted in other threads/users.

Finally, I gave up.

Your code really works fine now... :smiley:

Again, many thanks for your patience..!

=