Replies: 3 comments 1 reply
-
|
I added the ability to specify a relative directory + "\" + file name for filter type f: in commit 96fd846. If the filter does not contain "\", it will match only the file name as before. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the quick solution. I will try this out. By the way, for anyone reading sdotaka's answer, above, it is the backslash character that the new code searches for. If a backslash is found in the filter the directory and filename are passed into the rule whereas if there is no backslash just the filename is passed in as before. While I won't be able to download try the latest code just yet I'm marking this as the answer because the described solution will definitely address my issue. |
Beta Was this translation helpful? Give feedback.
-
|
The latest binaries can be downloaded from: |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, this change was reverted soon after in 9566ccb... |
Beta Was this translation helpful? Give feedback.
-
Is it possible to filter a qualified file, meaning a specific file in a specific directory? What I'm really looking to do is filter .log and .pid from the \jobs directory, but not from other directories where those extensions may be used. I've tried every variation of regular expressions that I can think of and nothing seems to work (e.g. f: ^.\jobs\..log$). When I use the Test (Filter) option and I specify a fully qualified path or a relative path I get the results I expect -- files get filtered (reported as "failed"). However, when I run an actual compare the files I want to filter end up being included in the compare. The system behaves as if when the filename filter (f:) rule is being processed it is JUST the final portion of the filename being passed in for the compare, with no portion of the directory included.
While I personally would like to see a change where the filename being filtered against includes the directory, I can see that this could break some existing filters and be an issue for users upgrading. A solution to this would be to include a new filter type "c:" where c represents "complete". This would allow users to create filters for specific patterns in certain directories without having to globally exclude the same pattern across all directories.
(Another solution would be to look at the f: filter to see if a backslash is included as part of the filter. If it is then the user obviously intends for the full filename to be passed through the expression. This adds a level of complexity that I would not recommend but it is a possible solution.)
Beta Was this translation helpful? Give feedback.
All reactions