Recent changes to bugs

Critical crash when loading a partially calculated list from saved file

2013-08-13T19:49:30.744000Z

There is a bug when you save a partially calculated list of files, when you try to reopen the file in the program it gives an access violation critical error and closes.

Setting Tags with "Tag Matching States"

2012-06-25T02:51:46Z

I'm using the latest beta version 0.6.5.6000 Unicode 64

I use the "Tag Matching States/Not Calculated" to set tags. However, using this feature fileverifier fails to tag the first entry that has not been calculated .. It always begins tagging on the second entry that has not been calculated. So I must manually go back and tag the first entry.

This problem may have something to do with the process I use for tagging. I am calculating hashes on a long list of files. Since the process takes several hours I usually stop the calculation after an hour or so, to save the hash file .. I then use "Tags None" to clear the tags and use the "Tag Matching States/Not Calculated" to set the tags on files not yet calculated before restart.

The file that fails to get tagged was the last file running (getting its hash calculated) prior to stopping FileVerifier. Since I stopped FileVerifier mid-process, this file did not get its hash completed ... However, even though this file has no calculated hash ... its tag does not get set when using the "Tag Matching Status/Not Calculated". Hope this is clear.

App Crash Failure to load saved files

2012-06-24T03:35:40Z

I'm using the latest beta version 0.6.5.6000 Unicode 64

When I save using the fv "*.FVA" format, I am able to save and then later reload the FVA files without problem.

I then tried using the *.MD5 format. I am able to save the calculated hash data files without problem. However, when I try load the just saved *.MD5 file the fileverifier application will crash.

I noticed that fileverifier will not crash if the MD5 file only has a few entries in it. However, after loading, I can see that fv was not nable to parse any of the entries of the file (that was just created a few seconds earlier by fileverifier).

I then tried to save and reload using the *.CSV file format. Same problem. I'm able to save the file without problem but unable to reload it without crashing fileverifier. Again, it is unable to parse the entries.

strip common path doesn't strip ".\"

2012-03-18T01:59:56Z

I loaded a list into the Advanced Processing dialog. The contents of the list file is a single line:
.,desktop.ini;thumb*.db;,1,1

The list directory value in the entry is simply '.' - I made that change manually in my saved list so that I could use the same list in multiple directories or drives.

The file list is processed as expected and all files are listed in directory ".\*".

When I save the results, I am prompted "since the program options are set to use relative paths for hash entries, would you like to automatically strip the common path between each entry and the newly saved file" as expected. I answer yes.

However the ".\" is not removed from any of the files listed. I would expect the output file to be the same as if I had explicitly listed the start directory rather than made it relative to the list file.

Actual result:
<entry name=".\foo\...

Expected result:
<entry name="foo\...

File Calculations Work In Reverse Of GUI Order

2011-10-10T11:06:12Z

Testing: v0.6.6.6050

Despite changing the sort order with the columns, when validation begins, it works from the bottom of the main GUI towards the Top.

Don't Recalculate Doesn't Always Not Recalculate

2011-10-10T11:01:16Z

Testing: v0.6.6.6050

With "Don't Recalculate Known Good Items" selected and with a partial amount of tagged files already validated, when the calculation is stopped and a preference change is "Applied", calculation starts completely over. This despite already calculated files continuing to show in the main GUI that they are already validated.

Takes like 2 seconds to close when there are verified files

2009-05-19T23:04:05Z

Steps:
1) Open a .sfv file with multiple files (no need to verify).
2) Click the close button of the window.
3) The program seems freezed for about 2 seconds and then closes.

Program crashes when terminating directory recursion.

2008-09-01T04:18:58Z

Versions affected: v0.5.2.5113

Apparently, there's a problem with the program crashing when canceling directory recursion. The program crashes with an access violation, in which the accessed memory is not consistent. From what I can see so far, the program is crashing in a function called _emutls_destroy. I have yet to do more testing to determine the culprit, or if this affects earlier versions. At this time, my prediction is that it has something to do with the compiler change. If anyone else has noticed this problem, feel free to chime in here.

Menu Algorithms: there are two entries for JamCRC

2007-12-15T09:13:53Z

There are two menu items JamCRC in the menu Algoritms of FV.

Handling of large context menus.

2007-12-13T01:09:59Z

FileVerifier 0.2.0.3533 shell extension does not correctly handle situations where there are an extreme number of context menu items. A permanent fix will require adding a dialog to the application for the user to select the appropriate algorithm at run-time as the number of items allowed appears to be limited.