Hmm, that might be fixed with a simple call to create_directories before renaming, so the target directories will be created even if the original directories didn't match your regex. But that would lead to empty folders when the files from them have been moved.

-Tuxman (January 10, 2019, 06:56 PM)

The program is already set to rename/move files, not directories by themselves.
So leaving empty directories behind is both the correct, and expected, behavior. Moving everything out of a directory doesn't necessarily mean that the directory should be deleted, empty directories are a valid entity.

If you want to, it's of course possible to add an optional parameter to check if any directory is being emptied during the run (keep track of location for any file that was moved, and after processing everything check if any of the locations are empty), and then delete them. But, again, while that could certainly be nice, I think it's not required, and it's perfectly fine and normal for empty directories to be left behind if the files inside them were moved elsewhere.

If you allow moving between folders as well as renaming you may get into some interesting issues.

One problem is that you are not guaranteed what order you get files and folders in, so one run could have a move fail because the target file exists, while another can succeed because the file with the target name was processed earlier and moved.

For instance if you have x/x/x/ containing x/foo and x/x/foo, and you move foo to x/foo recursively, then if you process x/foo before recursing into x/x/, it will fail, but if you recurse into x/x/ and move x/x/foo first, then moving x/foo will later succeed.

Even worse, C++ does not guarantee if any files or folders created after you create the directory iterator show up in it, so you could potentially have a rename bomb if you rename for instance f(o+)x to f$1$1x.

-Jibz (January 10, 2019, 02:22 PM)

There are a couple of things that can be done to help with these issues.
1. Don't rename on-the-fly. Prepare a full file-list first on one pass, then rename files on the list on a second pass. Should be relatively easy to do, and prevents a rename bomb since a newly created name won't be caught again.
2. Do the rename "virtually" first, on the names in the file-list, checking if the result is in the file list, and if so then delay that file to a subsequent pass, and only actually rename files that successfully went through the check. Possibly repeat, as long as in each pass something does get renamed. Complicates things, possibly significantly. But won't fail to rename a file to something that existed originally but should be renamed/moved anyway later (e.g. running your "f(o+)x" to "f$1$1x" on a folder with "fox" and "foox").

I checked the new version.

Regarding 4, that's not it. Even without the -r flag, the ".\" is still considered a part of the file name.

Example: Trying to clean file names (replace various separators, including decimal dots, with spaces) with a few files in the local directory:

expected: "bla.txt" left as-is since it doesn't match, "file.with.dots.txt" changed to "file with dots.txt" . But the ".\" at the start doesn't let this happen.

Example: adding a prefix to any file (behavior is the same if the "(.*)" is replaced with something to filter, it just of course happens with the relevant/matching files  ) :

expected: file "bla.txt" will be renamed to "prefix-bla.txt", same with the other.



There's also another issue here (which would have interfered with the above even without modifying the ".\" ). It seems that it fails to rename anything when -E is used. It uses it correctly in what it shows as the expected file name, but fails to rename with the same "operation not permitted". This is once with -E and once without, same files, seemingly same wanted destination name: