(Just a bump to note the new beta, AllDup 3.9.28 Beta.
Needed because of Forum list - modified time.)
AllDup 4 release candidate
Re: AllDup 4 - Open Beta Test
Should "tree" be there?5100,"Compare only files within the same source folder"
I guess "same source folder" kind of implies subdirectories too, but if tree were there, might be a little clearer.5100,"Compare only files within the same source folder tree"
(I'd rather it say ...directory tree, but I guess the word "directory" is unfashionable .)
Re: AllDup 4 - Open Beta Test
Search box on the Search Results page is broken.
(Looks to have been that way since AllDup_3922beta. 3918 works.)
(Looks to have been that way since AllDup_3922beta. 3918 works.)
-
- Site Admin
- Posts: 4048
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: AllDup 4 - Open Beta Test
The search is not broken.therube wrote:Search box on the Search Results page is broken.
Before v.22 it was always a partial non-case-sensitive search.
Since v.22 its case-sensitive and supports wildcards.
Search string before: "text"
and now you have to use "*text*" to get "nearly" the same results.
I will add this to the ToDo-List:
- Add a button to enable/disable case-sensitive.
- Add a button to enable/disable wildcards.
Ok?
Re: AllDup 4 - Open Beta Test
*text* is certainly an awkward construct.
Just what wildcards are available?
>> seems to be "?" & "*"
Or is it regex: or something that?
>> no
And are they specific to an individual column or is an entire "record" treated as a simple "string", such that you could search for something like: "*test.*2009*"
>> each column is searched individually, but also, each column is searched
> meaning (potentially) a file named "test 123.456.2009"
> or a file named "test 123.456" with a date of "01/02/2009"
> or a file named "test 123.456" in a folder named "2009 holiday at the shore"
The last two examples could be odd, depending on just what you were wanting to find.
Like how do I find "test.*2009" with test being in the filename & 2009 being the date of the file.
(I see it now searches on all fields [Yes], I guess treats the whole returned record as a string? [No])
Even the fact that it searches (on all fields?) is going to be potentially confusing.
Even with *2009*, most would expect to find files with "2009" in their names.
I guess some will accept *2009* being in the path too.
Most would find it odd for a file dated "01/02/2009" to be returned, though some might want that.
If dates were formatted with "/" a search for "/2009" would eliminate most ambiguity in that respect.
("/" being illegal in filenames. [as well as, / ? < > \ : * | "])
But if dates format used a dash (-), then you're back to the same situation.
Other things to think about:
> wrap-around
> first/last notification (I'd think the status bar would suffice)
I would think most would want case insensitive, & then less then most would want wildcards.
(Much like Language [button]. I'd think most would use their selected language, then never change it, so if the Button were not there, no loss - so long as there were some option, somewhere, to choose the language, even if it were "under" the Info or About buttons or something like that [as there are no "traditional" menu-items at all on the main screen].)
So what, the open & closing "*" are more acting like a deliminator to indicate a "search" rather then necessarily having "wildcard" meaning? Much like how you would more ordinarily put a path with spaces within quotes.
And if that's so, then why not simply allow the usage of wildcards ("?" & "*" if that's what it is) within the search string & not require "*" as a deliminator at all?
Just what wildcards are available?
>> seems to be "?" & "*"
Or is it regex: or something that?
>> no
And are they specific to an individual column or is an entire "record" treated as a simple "string", such that you could search for something like: "*test.*2009*"
>> each column is searched individually, but also, each column is searched
> meaning (potentially) a file named "test 123.456.2009"
> or a file named "test 123.456" with a date of "01/02/2009"
> or a file named "test 123.456" in a folder named "2009 holiday at the shore"
The last two examples could be odd, depending on just what you were wanting to find.
Like how do I find "test.*2009" with test being in the filename & 2009 being the date of the file.
(I see it now searches on all fields [Yes], I guess treats the whole returned record as a string? [No])
Even the fact that it searches (on all fields?) is going to be potentially confusing.
Even with *2009*, most would expect to find files with "2009" in their names.
I guess some will accept *2009* being in the path too.
Most would find it odd for a file dated "01/02/2009" to be returned, though some might want that.
If dates were formatted with "/" a search for "/2009" would eliminate most ambiguity in that respect.
("/" being illegal in filenames. [as well as, / ? < > \ : * | "])
But if dates format used a dash (-), then you're back to the same situation.
Other things to think about:
> wrap-around
> first/last notification (I'd think the status bar would suffice)
Button or maybe a setting in Options (menu-item)?button
I would think most would want case insensitive, & then less then most would want wildcards.
(Much like Language [button]. I'd think most would use their selected language, then never change it, so if the Button were not there, no loss - so long as there were some option, somewhere, to choose the language, even if it were "under" the Info or About buttons or something like that [as there are no "traditional" menu-items at all on the main screen].)
So what, the open & closing "*" are more acting like a deliminator to indicate a "search" rather then necessarily having "wildcard" meaning? Much like how you would more ordinarily put a path with spaces within quotes.
And if that's so, then why not simply allow the usage of wildcards ("?" & "*" if that's what it is) within the search string & not require "*" as a deliminator at all?
-
- Site Admin
- Posts: 4048
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: AllDup 4 - Open Beta Test
I added some new options. see attached screenshot.therube wrote:*text* is certainly an awkward construct.
Please check this description: http://www.alldup.info/alldup_help/filt ... holder.phpJust what wildcards are available?
sorry, i dont understand what u mean...> wrap-around
> first/last notification (I'd think the status bar would suffice)
- Attachments
-
- alldup_search_box_options.png (10.7 KiB) Viewed 69140 times
Re: AllDup 4 - Open Beta Test
wrap-around:
"By default, the 'wrapscan' option is on, which means that when "search next" reaches end of file, it wraps around to the beginning, and when "search previous" reaches the beginning, it wraps around to the end."
http://vim.wikia.com/wiki/Searching
.18 wrapped around.
.22 does not.
In .22 when you hit the last search item, hitting the fwd-search again does nothing, in .18, it would "wrap-around" to the first search hit. Likewise with the back-search when you were on the first hit, would wrap-around to the last.
Similarly, a notification when you've hit the first/last match or when you've wrapped around the top/bottom, can be helpful. (Each only persist until the next search action is taken.)
Just gives a user a little hint as to what's going on.
"By default, the 'wrapscan' option is on, which means that when "search next" reaches end of file, it wraps around to the beginning, and when "search previous" reaches the beginning, it wraps around to the end."
http://vim.wikia.com/wiki/Searching
.18 wrapped around.
.22 does not.
In .22 when you hit the last search item, hitting the fwd-search again does nothing, in .18, it would "wrap-around" to the first search hit. Likewise with the back-search when you were on the first hit, would wrap-around to the last.
Similarly, a notification when you've hit the first/last match or when you've wrapped around the top/bottom, can be helpful. (Each only persist until the next search action is taken.)
Just gives a user a little hint as to what's going on.
- Attachments
-
- Vim Search Wrap Around.png (29.12 KiB) Viewed 69135 times
-
- Site Admin
- Posts: 4048
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: AllDup 4 - Open Beta Test
i added the additional option "Wrap the search after reaching the end or the beginning of the search result".therube wrote:wrap-around
Now everyone can set up his personal search preferences!
Re: AllDup 4 - Open Beta Test
suggestion: further speed improvement
Comparing by a checksum value is much faster then comparing byte by byte because the program needs to read the files only once.
But even reading those files once can take a long time when a lot of files need to be compared.
For that i would suggest an option to store the checksum in a file (together with the last modification date and size ? of that file for example).
The next time a compare is started the program can use the stored checksum of the files whose modification date (and the size ?) didn't change.
suggestion: byte by byte option
Why would someone use the byte by byte compare method if comparing by checksum value is so much faster ?
The only reason i can think of is that that person is afraid of a collision (although rare it can happen with checksums).
But this can be solved by having an option to compare "byte by byte only when the checksum values are the same".
If, in that case, a collision happens the two files will be marked as different because of the byte by byte comparison.
ignore exif metadata:
Can we help in anyway with implementing this option for jpegs with data behind the eoi marker ?
Comparing by a checksum value is much faster then comparing byte by byte because the program needs to read the files only once.
But even reading those files once can take a long time when a lot of files need to be compared.
For that i would suggest an option to store the checksum in a file (together with the last modification date and size ? of that file for example).
The next time a compare is started the program can use the stored checksum of the files whose modification date (and the size ?) didn't change.
suggestion: byte by byte option
Why would someone use the byte by byte compare method if comparing by checksum value is so much faster ?
The only reason i can think of is that that person is afraid of a collision (although rare it can happen with checksums).
But this can be solved by having an option to compare "byte by byte only when the checksum values are the same".
If, in that case, a collision happens the two files will be marked as different because of the byte by byte comparison.
ignore exif metadata:
Can we help in anyway with implementing this option for jpegs with data behind the eoi marker ?
Re: AllDup 4 - Open Beta Test
It's not always black & white, & one method is not always faster then another.Why would someone use the byte by byte compare method if comparing by checksum value is so much faster ?
Speed Comparison
See also, AllDupManual.chm (aka, Help), Speed Comparison Test.