AllDup 4 release candidate

[therube]

(Just a bump to note the new beta, AllDup 3.9.28 Beta.
Needed because of Forum list - modified time.)

[therube]

5100,"Compare only files within the same source folder"

Should "tree" be there?

5100,"Compare only files within the same source folder tree"

I guess "same source folder" kind of implies subdirectories too, but if tree were there, might be a little clearer.


(I'd rather it say ...directory tree, but I guess the word "directory" is unfashionable .)

[therube]

Search box on the Search Results page is broken.
(Looks to have been that way since AllDup_3922beta. 3918 works.)

[Administrator]

Search box on the Search Results page is broken.

The search is not 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?

[therube]

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

button

Button or maybe a setting in Options (menu-item)?
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?

[Administrator]

*text* is certainly an awkward construct.

I added some new options. see attached screenshot.

Just what wildcards are available?

Please check this description: http://www.alldup.info/alldup_help/filt ... holder.php

> wrap-around
> first/last notification (I'd think the status bar would suffice)

sorry, i dont understand what u mean...

[therube]

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.

[Administrator]

wrap-around

i added the additional option "Wrap the search after reaching the end or the beginning of the search result".

Now everyone can set up his personal search preferences!

[Evds]

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 ?

[therube]

Why would someone use the byte by byte compare method if comparing by checksum value is so much faster ?

It's not always black & white, & one method is not always faster then another.

Speed Comparison

See also, AllDupManual.chm (aka, Help), Speed Comparison Test.