[PowerRename] Bulk regex rename needs to include folders

[garretwilson]

I read that this utility would allow renaming multiple files with regular expressions. There was a checkbox to exclude folders, so I thought if I unchecked that it would include folders. Apparently my expectation of "include folders" doesn't match how the utility works.

I have a lot of files in the form:

• 2019\02\05\foo.html
• 2020\04\03\bar.html

I want to rename them to the form:

• @2019-02-05-foo.html
• @2020-04-03-bar.html

I figured I would match some regex (\d\d\d\d)\\(\d\d)\\(\d\d)\\(.+)\.html and rename that to @$1-$2-$3-$4.html. It seemed straightforward to me. Looks like the utility can't handle it, though; apparently it only looks at the filename.

You might make this shortcoming explicit in the documentation.

[chrdavis]

Thanks for the feedback. It wasn't a scenario I had in mind.

[jwshields]

I would also like to +1 this suggestion.
I am in a similar situation with some of my files and wanting to rename them - It would be absolutely grand if this tool had the ability to consider the relative/full path to items;

I do love the ability to include/exclude both files and folders, but maybe this could be an addition to the checkboxes Item Name Only & Item Extension Only so that users could have the ability to toggle whether the path is taken into consideration. (Something like "Include Item Path?" - Spitball suggestion)

My only thought outside of that is wondering if the file/folder inclusion & exclusion filters would/could interact negatively with something like this?

I do hope this suggestion makes its way into the application though- The work on this modern version of PowerToys is much appreciated, thank you!

[Jay-o-Way]

Actually, this needs a FileRename AND a FileMove action. Because files and directories are quite different things. The numbers are not a part of the files or the folders, but only of the paths. So it is correct that it doesn't work for now.

This leaves open the question what to do with the folders after moving the files. Leave them be, possibly empty? Or delete them? But what if they are not empty? And so on...

I totally understand the request though. Had similar situations in the past with images from a camera, in a YYYY\MM\DD directory.

[garretwilson]

Actually, this needs a FileRename AND a FileMove action. Because files and directories are quite different things.

I understand where you're coming from, but another common conceptualization is that from a naming standpoint they aren't so different. For example in Linux you "rename" a file or a directory by using the mv (move) command. (Which is backwards in a way; when you "move" a file or directory in many times I would guess that its name mapping is updated; it doesn't probably actually change the physical location on the disk. So it might have been more correct to have Linux use a "rename" command for everything. But regardless of what it's called, the same command is used for both operations.)

The numbers are not a part of the files or the folders, but only of the paths.

That shouldn't make much of a difference if the utility were updated to allow path matching. Something like "rename (\d\d\d\d)\\(\d\d)\\(\d\d)\\(.+)\.html to @$1-$2-$3-$4.html" would get translated to some API call analogous to the following command:

move 2019\02\05\foo.html 2019-02-05-foo.html

The program can easily check to see if the API for "move" or "rename" should be called based upon whether the file is in the same directory or not. In fact I wouldn't be surprised if the API doesn't even distinguish between the two. As mentioned above, Linux would not bad an eye and would use mv for everything, regardless if the file was changing directories.

And just like a "move/rename" command, I personally would be completely fine if it left the original directories.

If you want to consider a replacement pattern replacement that includes the whole path (i.e. renaming path segments in addition to the filename), that would be more complicated and an interesting discussion. But for now I just need to include the path in matching, not in replacement. (Actually I don't need it anymore; I solved the problem in another way. But someone could use this, and one day I may need it again.)

[Jay-o-Way]

Actually, you are right. I have worked with a BASIC like program and it explicitly lacks a FileRename() function, because FileMove() does this. What I meant was that PT Rename searches only in the individual names for folders and/or files. Also, I think I mentioned them both to emphasize that files are being moved to a different location, which may be unexpected, if the regex search is done wrong. Notice that regular expressions use backslashes for entirely different things. But yes, it is an interesting idea to include this possibility. The renaming would still be a piece of cake.

Just make sure that people are aware this may move files to a whole different location.

[garretwilson]

Do you mean that the files would only change the name, but stay in the same original folder?

No. I gave examples using relative paths, so the following two files represents "moving" a file to another directory:

• source: 2019\02\05\foo.html
• destination: @2019-02-05-foo.html

Actually when I said "for now I just need to include the path in matching, not in replacement", I think I said that incorrect. Now that I think about it, the regular expression would apply to the entire path as well. I guess I confused myself because in my example I don't include any path in the replacement. But I suppose you certainly could.

Yeah so this should easily work just by having an "include path" checkbox, and have the regular expressions match/replace apply to the entire path as a string.

[Jay-o-Way]

Okay, I think we are on the same page now. To summarize: I believe it is a welcome new option, but it must be used with caution, because having one type error in the regular expression (using backslashes) may - unintentionally - move files to a totally different location. Maybe add a warning inside the check box label? Or a red label that appears when checked.

[enricogior]

Let's do it when switching to WinUI 3.0

[hyoretsu]

So, have we not switched to WinUI 3.0 yet or what? Just needed this feature to avoid more complicated solutions or manually renaming thousands of files.