DonationCoder.com Software > DC Member Programs and Projects
remv: Rename files (and directories) with regular expressions
4wd:
Why do I even publish software one year in advance if people don't test it before it's too late? ;D-Tuxman (January 09, 2019, 02:40 PM)
--- End quote ---
I was having a break from thinking last year :)
yarond:
I don't think the program should exclude itself in any way. I'm fairly confident no other file renamer/mover does so.
Any file that actually fits the pattern, fits the pattern, and should be processed.
For most normal operation, that's a non-issue anyway, the program will most likely not be in the relevant directory. When it is, outside of specifically the case of testing the program, then if it fits the pattern it's very likely to be intentional, by someone trying to move/rename it specifically (someone placed it in its own directory), or a bunch of portable utilities it's placed with (someone placed it in a utils/bin/programs folder).
Jibz:
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.
Tuxman:
Version 1.2.0 should recurse backwards. :-[
yarond:
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)
--- End quote ---
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").
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version