avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Sunday October 25, 2020, 6:21 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - yarond [ switch to compact view ]

Pages: [1]
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.
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.

Hmmm... With 1.2.0 , -nvv shows skipped files, -nv doesn't show skipped files, but does add a newline for each one.
C:\tmp\test>remv -nv f(o+)x f$1$1x
 Can't rename .\fox' to '.\foox' - file exists.
 Would rename '.\foox' to '.\foooox' ...

 [STATS] The simulation suggested 1 renames. Note that some of them might fail.

C:\tmp\test>remv -nvv f(o+)x f$1$1x
 Can't rename .\fox' to '.\foox' - file exists.
 Would rename     '.\foox' to '.\foooox' ...
 Skipping         '.\file.with.dots.txt' ...
 Skipping         '.\blab-habs-dot.txt' ...
 Skipping         '.\b' ...
 Skipping         '.\a' ...
 [STATS] The simulation suggested 1 renames. Note that some of them might fail.
after deleting the other files:
C:\tmp\test>remv -nvv f(o+)x f$1$1x
 Can't rename .\fox' to '.\foox' - file exists.
 Would rename     '.\foox' to '.\foooox' ...
 [STATS] The simulation suggested 1 renames. Note that some of them might fail.

C:\tmp\test>remv -nv f(o+)x f$1$1x
 Can't rename .\fox' to '.\foox' - file exists.
 Would rename '.\foox' to '.\foooox' ...
 [STATS] The simulation suggested 1 renames. Note that some of them might fail.

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.
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 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).

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:
c:\tmp\test>remv -Evv "[-+._]" " "
 Processing '.\bla.txt'.
 Renaming     '.\bla.txt' to ' \bla.txt' ... error: operation not permitted
 Processing '.\file.with.dots.txt'.
 Renaming     '.\file.with.dots.txt' to ' \file with dots.txt' ... error: operation not permitted
 [STATS] Renamed 0 files (2 failed, 0 skipped).

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  ) :
C:\tmp\test>remv -Evv (.*) "prefix-$1"
 Processing '.\bla.txt'.
 Renaming     '.\bla.txt' to 'prefix-.\bla.txt' ... error: operation not permitted
 Processing '.\file.with.dots.txt'.
 Renaming     '.\file.with.dots.txt' to 'prefix-.\file.with.dots.txt' ... error: operation not permitted
 [STATS] Renamed 0 files (2 failed, 0 skipped).

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:
C:\tmp\test>remv -Evv (a) $1b
 Processing '.\bla-has-dot.txt'.
 Renaming     '.\bla-has-dot.txt' to '.\blab-habs-dot.txt' ... error: operation not permitted
 Processing '.\file.with.dots.txt'.
 [STATS] Renamed 0 files (1 failed, 1 skipped).

C:\tmp\test>remv -vv (a) $1b
 Processing '.\bla-has-dot.txt'.
 Renaming     '.\bla-has-dot.txt' to '.\blab-habs-dot.txt' ... Successfully renamed .\bla-has-dot.txt to .\blab-habs-dot.txt.
 Processing '.\file.with.dots.txt'.
 [STATS] Renamed 1 files (0 failed, 1 skipped).

Perfectly understandable. And thanks for the quick response.  :)

And of course what I present here are just my opinions, as much as I personally may think they're valid and correct one.

3. If the regex engine you're using doesn't support something like this, then of course not much you can do. But generally most (all?) user tools for search&replace that I can quickly think of (and regex code/development libraries) allow something like a "fake" backreference to the full match. Usually (in my experience) that's done by something like $0 or \0 (e.g. a capturing group for everything before the first actual capturing group) for tools that otherwise use $n or \n , . It's mostly a convenience thing, so not strictly necessary, but it's a very common one ("why do I explicitly need to indicate the group boundaries when this group is already very clearly defined, and is already a known individual entity to the engine?"). Though, again, yes, if it's not something that your regex engine handles, then it's technically correct, so this does downgrades to feature-request rather than bug.

4. Oh, I like that as a feature, for sure. But I think it should be done only if the user explicitly wants to use it, otherwise it should just be assumed.
If the user didn't explicitly provide the location, then it shouldn't match anything on the input regex. If working on "file.ext" in the current directory then it's called "file.ext", not ".\file.ext". If the user wants to move it somewhere then they don't replace .\(.*) with c:\somewhere\$1 , but rather (.*) with c:\somewhere\$1 . This should carry fine to sub-folders of the current folder.
If not using the current folder (or using sub-folders in the pattern) then the user needs to specify the path explicitly anyway, so no problems there. The ".\" should be a valid destination location (I didn't check if it is now), but shouldn't be matching on the input unless explicitly put there by the user.

5. Since it's posted here as a windows tool, file extensions are very much a separate part of a file name, both for the O/S and for the expectations of the very large majority of users. Files with ".tar.gz" are handled by programs that know how to open ".gz" files, which hopefully also know to notice that the base name ends with ".tar" and what it means (which for practical purposes I think anything that handles ".gz" is aware of). But as far as the O/S is concerned, when making file associations/icons/filters, that file has a ".gz" extension. And file renaming can often includes the desire to change the file name without touching the extension.

Nice idea, and certainly can be useful.

After a quick test on Win10, there are some problems:
  • When providing an invalid input pattern, but trying to provide an option parameter, the shown error text quotes the parameter as the input regex (e.g. "remv -n [a $1" returns error message "remv could not parse your input regex: -n")
  • Running valid regex without any options does nothing, running with -n (simulate) just writes some empty lines to console, running with -v (verbose) actually renames while also indeed being verbose. I haven't checked other options yet.
  • For replacement pattern $0 isn't valid, and treated as a literal (e.g. "remv -v .* pre$0" will rename file1.ext to "pre$0" instead of "prefile1.ext", and then will error that it can't rename "otherfile.ext" because "pre$0" already exists). Of course there's the workaround of explicitly putting the matching pattern in parenthesis, but it shouldn't be required and something like $0 should work for the entire pattern.
  • When renaming files in current directory (I didn't test any folder/directory/move handling so far) the verbose display (which as mentioned for now seems a must) lists each file as starting with ".\" before the name. That's... technically correct (the files are in the current folder), but not really expected (or helpful) when renaming files locally without any indication from the user that the location should be managed.  Worse, the ".\" at the beginning of the file name also matches the input regex. So doing something like "remv -v (.*?)(\..*$) $1 $2" fails for trying to rename the folder, to "a.\" (instead of trying to add a space before the first period in the file name) which results in an appropriate "operation not permitted"
  • This one is more of a feature request than a problem, but for file-name handling it's a very common/basic feature (and also partially related to the previous item): It should be possible to treat the file extension separately, with something like an optional parameter to specify whether it should/shouldn't be considered as a part of the regex. Otherwise this will just require a heck of a lot of "(.*)(\..*$)", or somesuch, in matching pattern and replacement group when wanting to rename files without modifying the extension

Find And Run Robot / Re: Running FARR (and other) on virtual desktop
« on: November 01, 2012, 12:20 PM »

I know I'm reviving a really old thread here, but since it does contain the background I figured it will be better than starting over.

Basically I came up the same problem, I've started to test Desktops, and have the same issue with FARR opening its window on the original first desktop rather than the active ones.

But... Looking a bit at the relevant APIs and documentation, I think that handling this is fairly straight-forward, and depending on what FARR does behind the scenes might even be very quick and easy.

So, some additional details that were missed in the original discussion: True, there is no way to transfer windows between desktops. But, and it's a big but, there is no problem creating new windows, from new threads, on different desktops.
Once an application thread interacted with the UI it's locked to a desktop. But a new thread, on the same application, can work with other desktops (such as the "currently active" one) without a problem.

The cost on the program is to have a different UI thread for different desktops. Which depending on how the existing code goes would mean either creating a new UI thread any time the window is shown, or instead just creating new duplicate threads for different desktops and keeping that pool.

For example, basic C code with WIN32 API that creates a message-box on whatever the currently active desktop is. Calling this from within the thread procedure, before the thread interacts with any windows, creates the messagebox on the active desktop instead of the one originally used by the application:

Sleep(4000);   // Just to give the user time to switch desktop for testing, without any UI interaction
HDESK hDesk=OpenInputDesktop(0,TRUE,GENERIC_ALL);  // Gets the currently active desktop
if (hDesk!=NULL)
BOOL bSuccess=SetThreadDesktop(hDesk);  // fails if the thread already interacted with a window, but on a new thread should be fine. Also, if keeping existing threads and switching between them then this isn't needed when hDesktop is known
if (bSuccess)
MessageBox(NULL,TEXT("Switched to the active desktop"),TEXT("Success"),MB_OK|MB_ICONINFORMATION);  // This will appear on the active desktop
CloseDesktop(hDesk); // Not to leak the handle
} // No error handling in this sample, but it won't fail if the thread really didn't do any UI interactions.
} // No error handling in this sample. But shouldn't realistically fail when generated by a user on the computer since there will be a desktop

Any chance of you considering making such a change in the foreseeable future? I really do like the behavior of Desktops compared to the other (hide/show windows) programs of the type, but using FARR with it currently is very clunky.

N.A.N.Y. 2012 / Re: NANY 2012 Release: Ethervane Echo
« on: January 25, 2012, 09:33 AM »
yarond, welcome to the site!  :D

Thanks.  :)
Been an occasional reader in some of the forums here for a while, but as a rule I try to follow the "if you don't have anything to say then don't say it" creed.

N.A.N.Y. 2012 / Re: NANY 2012 Release: Ethervane Echo
« on: January 23, 2012, 09:34 AM »
I agree with you all the way and have added your idea to the wishlist.

Thank you.

A better alternative is to be able to say "this application *and* any of these (partial) window titles". It would provide for better fine-tuning of the filters.

I agree.

I think that the potential disadvantage here (if someone does want to block storing from the same source for multiple different programs then they'll need to define it multiple times in the filter) is better than the, probably much more likely, alternative of a risk of matching also unwanted and unexpected windows.

N.A.N.Y. 2012 / Re: NANY 2012 Release: Ethervane Echo
« on: January 22, 2012, 05:24 PM »

First thing, thank you for the program. I switched from ditto after a few years of using it, since Ethervane Echo covers some of the problems I had with it, without losing anything that I really used. So far, after a few weeks of testing it, it seems to work very well.

I do have a feature request, relating to the option not to store clips from certain programs (one of my issues with ditto).
For most cases basing this on the application is the right thing to do and exactly what is needed. But there are cases where it would be nice to be able to selectively not store a clip based on part of the title too (well, based on the context, but title is the only technically feasible way to do that usually), and not for the entire program.

For example in cases where maybe there are just a few business of financial documents that contain sensitive data that shouldn't be stored someplace else, or anything copied from the browser when on the site of a bank or some web/javascript password manager, cases where instead of a passwords are stored in a general encrypted note-taking application and other notes from there should be stored, and so on...

I don't think it's a widespread need, but there are some cases where it will make my life a bit easier (some, though happily not all, of the examples above), and I think it's also not that rare.

Adding to the application filter list some way to add modifiers to the program name, which must exist on the title of the window copying from, would probably be good enough.

I'm not sure if it's a good idea to also allow a title filter for all programs or not. On the good side it will work for websites when using multiple browsers, or documents that may be opened with multiple programs. But on the other hand it will probably complicate things, it will increase the chance of accidental matches, and realistically I think any file of website with sensitive information is probably not opened with more than one, or maybe two, programs on a regular basis.

Pages: [1]