#9 Follow Current File

open
nobody
5
2011-10-10
2011-10-10
Anonymous
No

Testing: v0.6.6.6050

Is it possible to have the Main GUI follow (track) the current file being calculated? One way would be to have the Validation dialog box detached (unlocked) from the Main GUI so that the user can manually scroll up and down, or auto-scroll, to follow the current file. Alternatively, the Validation dialog box could remain locked to the Main GUI, and just have the program auto-scroll. This would be handy when you have many files that exceed the height of the Main GUI, such as when I used 13,000 files, in several nested directories, as a test. This would also be useful since the Validation dialog box has a fixed size and it is not always possible to know which file the program is calculating.

Discussion

  • Tom Bramer

    Tom Bramer - 2011-10-10

    A start here would be to at least improve the verification progress dialog display in terms of the current file being processed. Unless most of the files you're hashing are greater than 10 MiB or so, you probably wouldn't see much if the list view auto scrolls, considering up to a few hundred files could be hashed per second. Another issue is that as you have already discovered (based on your other reports) that the order that the files are processed is not influenced by the display order. The program does this for performance consistency reasons. While the order in which the files are processed is not the most optimal, it's likely better than random, depending on the file system's block allocation strategy. This is based on the idea that often, most of the files in a directory are created in the same time frame, and if a best fit strategy is used for allocating disk blocks for file usage, the files may be created near each other on disk.

    I will keep this all in mind for the next version.

     
  • Nobody/Anonymous

    To address the first point in your reply; as a amateur photographer that shoots in Large JPEG and RAW images, hard drive space becomes an issue. Because of this, I compress each set with WinRAR, splitting the archive at 50,000,000 byte parts. The 13,000 item MD5 test file (I mentioned before) mostly represents 13,000 50,000,000 byte files and is used to check all saved sub-directories in one single event, something that is impossible or very cumbersome with the WinRAR test itself, or with PAR2 or SFV. Each RAR set includes a built-in 5 percent recovery record and each directory contains 20 percent PAR2 files for recovery purposes, to be used on a new hard drive, should a file be determined to be damaged with the master MD5 file. The hard drive is only powered up when new archive files are to be added, but before adding new files I always test the hard drive with the master MD5 file. There is probably better ways to do this, but for years this is the way I've been doing it.

    To address the second point in your reply; every so often I perform a PerfectDisk defrag on the hard drive to reorder the drive contents. I realize this doesn't change how FV++ works, I'm only mentioning this that the original created allocation isn't always the same.

    Thanks.

     
  • Tom Bramer

    Tom Bramer - 2011-10-19

    I can see where this would be useful in your case (hence most files being greater than 10 MiB), though I don't think it makes sense for small files. The update rate would need to be artificially limited in order to not impact performance (as in most cases, it would). It would be a rather substantial change to make to the program.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks