XnViewMP, version 0.64 for windows, tested 32-bit and 64-bit.
Results seem to be different between windows 7 and XP, and it is a bit hard to know how many separate bugs/features are involved, so I shall initially list them here and they can be split later if needed.
If the current browser view is in "details", "icon" or some other mode that does not require thumbnails, then every single thumbnail in the DB is zeroed. This seems to be a strange choice. If the logic requires this, then the button should be labelled "delete thumbnails" in these cases.
Windows XP, 32-bit. The operation on the DB seems to be carried out as expected, but the dialogue never returns. The progress window just sits there, with the abort button inactive.
The close ('X') button removes the progress window, but the Settings window never redraws. Closing the Settings window results in a confirmation to kill the program.
Windows 7, 32-bit and 64-bit generally perform the operation and return as expected (with the state as outlined by observation 1). I initially got different results on the systems, but I later realised it was because one system had the browser in details display mode, while the other was in thumbnails.
Windows 7, both bitsizes can be made to hang, but the conditions are a bit different and the abort button remains active. This happens when a network share is included in the db, and the share is currently inaccessible. This happens both with UNC paths and with mapped drives.
The rebuild seems to occur in the db up to the missing folder (with folders being processed in alphabetical order).
It can be triggered in a number of ways:
- The other PC/server is offline
- the drive is not currently mapped
- the mapping references a different path (i.e. different external drive)
This is perhaps weirdest - I renamed one of the folders cached in the db on my local hard drive. Even that caused a hang when I pressed "rebuild thumbnails", rather than simply going to the next folder in the db. But the bizarre thing was that the progress box showed the new folder name, which was not in the db. Maybe it just a coincidence that it was next folder alphabetically on the disc.
There's a touch of irony here, considering recent postings .