Changes in this update are listed in the release notes.
I strongly encourage all beta users to update to 0.32 as soon as possible.
Please visit the beta page to download version 0.32.
Changes in this update are listed in the release notes.
I strongly encourage all beta users to update to 0.32 as soon as possible.
Please visit the beta page to download version 0.32.
Downloaded the new verison, running the verify now. It normall hit the errors within 10 mins, and we have past that point. I will edit with the final results when it completes.
First verify run found several dozen errors and fixed them. Second verify run being performed now.
I completed the second verify with no errors found. I then deleted a few files on one drive and moved some files to a new folder on the same drive. Windows does not physically move the data, just alters the pointers to where the data is found. The scan of the changes was quick, but it has been sitting at "Scan Complete. Analyzing Results..." for about 10 mins, but it finally figured everything out and now I am running the update; it found all the changes.
Yes when a file is moved, disParity has to hash the file in the new location to make sure it's still the same file as the old, and that can take a while for very large files. I know that Windows doesn't physically move the file, but I haven't been able to figure out any way to guarantee after the fact that they are actually still the same file other than to re-compute the hash value.
I would rather err on the side of caution. I care far less that the update takes a long time when moving files on the same drive than I do having the correct parity info.
If I was running something more modern than a Dual Core Pentium E7200, it might not take as long to run. :)
I ran the verify after the last update and it found errors again. It fixed them, though. So far, each time I had to do an update it found errors right afterwards.
Interesting. Sounds like something is still not quite right. Can you email me another log file, hopefully one showing an update and the verify right afterwards with failures? Thanks!
First, a word of thanks to Roland for sharing disparity and working to solve bugs through your holiday time. I have used 0.21 for a long time, but never posted before, 'cos when I discover disparity, the forum was already pretty quiet.
I am seeing the same issue as cybrsage with v0.32.
To vary the test, I rebuild parity from scratch using 0.32. Two 1.5 TB drives and one 1TB drive. Now doing verify. About 10% in, and there are already more than a dozen errors.
The verify is being done right after the rebuild, with no adds or deletes in between.
I am running a fresh verify right now immediately after doing an update. I removed several files - 2 large BluRay ISOs and 4 or so smaller picture and xml info files (used by Media Browser). The verify is half way through my multiple terabyte array. I will email you the log file once it is done, it will include the last two updates and verifies in it.
My latest verify went through just fine. Do you still want my logs?
Yes, please send me your log. The log file doesn't get overwritten each time your run disParity, so it may still contain information from your earlier verify that failed.
sub0 - thanks for joining the forum and sending your feedback. When your verify completes, could you also email me your log? It should be here:
C:\Users\[user]\AppData\Local\disParity\logs\disParity.log
My address is rolandv@gmail.com. Thanks!
Meanwhile I'm running a Verify test on my primary media server now, trying to see if I can repro the problem here. No errors so far, so it might be that your logs will be the only clue I can get for now.
Verify completed with 30 errors or so. Just ran a 2nd verify just to see if errors found earlier on the first run were fixed. Past 10% point with no errors found (on first run, a dozen or so errors were found and fixed by this point). I have cancelled the 2nd verify run.
So I guess the question is: is verify finding false positives or is update creating errors?
One thing I noticed:
During the parity build, the display shows ( for eg):
"files protected 1 (size of that one file)" when dispartiy is already processing the 4th file on the drive. It always shows 0 files protected when processing the first 3 files on any drive. (However, "files*.dat" will first show up in the parity drive when 2nd file is being processed on that drive.)
If this is just due to delayed reporting/display, then not a problem. Otherwise perhaps it indicates data is lost somewhere?
Roland,
I will email you the log shortly.
Thanks for the logs, it took some head scratching but eventually I was able to spot the bug!
It applies to files with a length that is both larger than 4 GB (i.e. 2^32) and an exact multiple of 64K. It causes Verify to report a single incorrect block at the end of the file. Unfortunately, it then "repairs" the block incorrectly.
The good news is, I'll have a fix out shortly, and in the new version, Verify will fix the block again, correctly this time. So if you ran a Verify pass in 0.32 and it found and fixed any errors, you should run another one in 0.33.
It should also fix the file count reporting bug you mentioned.
You must log in to post.