Multi-file Rename, /, causes directory creation

[therube]

I don't know if it's a feature or not [OK, so it is], but with a Multi-file Rename (F2), a / (or \) causes directory creation.
So... (F2)

test -> x/test

creates (if necessary) & moves test into (a directory named) x.

I imagine ? there's a setting to disable this?
I'm thinking that maybe it should be disabled by default? Maybe*.

I sort of knew something like that existed for 'Copy to' ('Move to'), guess I just didn't realize (though suppose I should have), that it also applied to Multi-file (Advanced) Rename.
(Heh. And looks like Shift+F2 is not a default for Advanced Rename. [Wonder if I put that in there, long ago?])

Add folder name to rename files

Maybe*

So now realizing that it is expected (& just something I hadn't run into before), & knowing the behavior exists, I guess it's OK, defaulted.
(And far less of an issue that it might otherwise have been, given that Undo History & Index Journals exist.)

[void]

Moving files to another directory is unexpected when renaming files.

The next alpha update will throw an error when the new name contains a \ or /.

[horst.epp]

Moving files to another directory is unexpected when renaming files.

The next alpha update will throw an error when the new name contains a \ or /.

Moving files with rename is a very welcome feature in some file managers
and not a surprise when one uses \ inside of the new name.

[void]

I've put on my TODO list to add an option to allow files to be moved when the new name contains / or \

For now, please use the Advanced Move options under Edit -> Advanced.

Everything 1.5.0.1258a will now give a 'Invalid Filename' warning when the new filename contains a / or \

[void]

Everything 1.5.0.1259a adds a rename_move ini setting to allow moving of files to another directory with / or \ when renaming.

To allow moving when renaming:

• In Everything, type in the following search and press ENTER:
  /rename_move=1
• If successful, you should see rename_move=1 in the status bar for a few seconds.

When enabled, you can use relative paths, or new absolute paths.

For example:
move a file up a folder:
filename.txt => ..\filename.txt

move a file to another folder:
filename.txt => d:\archive\filename.txt

[therube]

1259.

move a file to another folder:
filename.txt => d:\archive\filename.txt

So far, unable to get that to work?
(../ or ../tmp/ does work.)

[therube]

Collisions aren't handled gracefully.
But then I guess it would be up to us to make sure there aren't (collisions).

[therube]

Should the name-part be required?
As in instead of giving a "new" name, simply provide a new path (leaving name-part unchanged).

[void]

Thanks for the feedback therube,

I will address these issues for the next alpha update.

[void]

Everything 1.5.0.1260a fixes an issue when using the multi-file renamer, enabling rename_move and moving a file to a new absolute path.

For example:
Plugins-1.5a.ini => c:/tmp/Plugins-1.5a.ini

Collisions aren't handled gracefully.

The multi-file rename/move will fail if a file already exists.
Showing a Yes/No dialog here is dangerous when moving hundreds of files. (User might not read the dialog or might be spamming Y/N to another dialog)

A log shown at the end of the rename might be more useful here.
Rather than interrupting the user several times, have a log showing the failed renames.
... added to my TODO list

Should the name-part be required?

For the multi-file renamer, yes.

For a single rename within the Everything result list, no.
I have added support for this in Everything 1.5.0.1260a.
rename_move will need to be enabled and you will need to specify a folder.
For example: Plugins-1.5a.ini => c:/tmp
Only works for files (not folders), unless you specify a trailing path separator.
For example: My Plugins Folder => c:/tmp/