Folder Colors; File counts -- problem or misunderstanding?

[jmthomas]

My screen:


Questions --

1) Why are all folders the same yellow color? I'm used to seeing them with different colors to indicate the status of the files within. For example, a folder contain orphans would be 1/2 blue.

2) Why are the to be deleted counts off when there are no hidden files? The left side is correct, but the right side is WAY off. Note there is no eyeball icon on the delete dialog confirmation or warning that files are hidden.

Finally, this may be a clue; I've been copying and experiencing CRC checks.


The delete at 5:25:50 was for all files on both sides in folders Lewis-1 through Lewis-2-1, done with a block selection starting with Lewis-1 at top and the last file in Lewis-2-1 at the bottom. When not everything was deleted, I did a fast refresh to make sure the screen was consistent. Then I got ready to try deleting the failures and stoped when the confirmation screen was not correct.

I'll hang on to this disk configuration for a couple of days in case you want me to experiment.

I'm running BC4 build 19761:
Removed for privacy

[Aaron]

Hello,

A yellow folder means the folder has not been fully scanned. I suspect there is a yellow item that does not have content/fails to expand as a subfolder to these folders. Since it fails and is still yellow, that color is propagated to all parent folders as well, to indicate they are not fully scanned.

If files are failing a CRC check, that usually points to some kind of corruption. We may have failed to get the full file listing, or been unable to read directories when attempting to load them that Explorer was able to open. Does a refresh/full refresh show more or less content? If so, I would suggest backing up your drive asap.

[jmthomas]

The directories are OK. Check Disk has been run and has blessed them.

The CRC errors are (generally) repeatable and in the data itself. This can be demonstrated by individually coping files, and watching for the I/O error to happen at the same point midway into the file. And occasionally, thank <deity>, a damaged file will actually copy OK.

An aside about modern disks...

Somewhere about the time platters exceeded 500 - 650 GB, a decision was made by the industry to give up on 100% faithful recording, and depend on error correction. In other words, failure to read a sector correctly would no longer cause the data to be relocated and the sector placed out of service. Such actions were reserved for multi-bit stream errors where it is believed that there is significantly increased risk of error correction not working with future reads.

The race to the bottom has made "correctably flaky" the new standard.

In a way, this can increase ultimate recoverability. By not relocating known bad data, but leaving it to be re-read, future raw reads might see a different corruption of the data -- one that error correction can repair.

So yes thank you, I'm aware of the potential disk failure on the horizon. I'm using BC to verify copies to my replacement hard disk.

1. Thank you for the explanation for yellow folders. I'll watch carefully in the future, but I don't believe any of the scenarios (missing compare information) you describe apply. More news later.

2. How does a compare result "incomparable because of I/O error reading one or both" count? I'd expect it to tally as "not equal" as far as coloring folders. And if nothing else, sub-trees where there were no I/O errors should show a colored result, right?

3. As far as the folder/file counts being off, please recall that I did a quick refresh just before the delete. Should not have this quick refresh verified names, folder structure, and counts?

4. I don't know if BC does direct access to NTFS directory information, or depends on NTFS itself. If NTFS can't read directory information, it (not to be confused with WE) makes a noticeable complaint which I have not seen.

Therefore I still wonder if data I/O errors might cause internal book keeping problems for BC.

[Aaron]

2. Right, if a folder can be read and comparison results gathered, it should have a color, so if a folder is yellow a child item (file or subfolder) had the error state within it.

3. A Quick Refresh would check for changes in the current folder structure. However, as your disc may be having trouble returning accurate information, we may be failing to detect a change within an error section? A Full Refresh would throw away any information we have, and reload the session from scratch.

4. I can check with a developer on the exact nature of our listing, but we return most error text we encounter directly to the log. That's why many of "our" error messages may be generic or difficult to parse. They aren't actually generated from BC4; we're displaying what another process is passing back to us.

If your disc is having hardware failure issues, it may be unreliable and return unexpected results. Hopefully that isn't the case, but even on large harddrives we do not see this type of log information when dealing with large datasets. On my own machine I routinely work with my 2TB hdd, and we have many other customers with similar or larger configurations.

[jmthomas]

Let's make one thing clear. All my disks are OK.

I have removed the defective one from my case and its setting on my desk. There haven't been any I/O errors since I did that on the 10th of April. My system volume was never in error. Only one of my data volumes was throwing read errors, and it has been replaced and the data recovered/verified from backups.

Thank you BC4 for the great verification job!

However, the problem with folder colors continues, even after uninstalling an re-installing BC4.

Please explain this screen:

BTW, it's a png image, so you can zoom in effectively by using Ctrl-+ in the browser window.

1. The "processing icon, just to the left of the filters box, has stopped flashing and is grey. I assume this means the scan is complete.

2. Several folders on the left are Clear/white, which generally means a scan is still going on.

3. As the Session settings show, no contents are being compared, so things should go fast. (Yes, these are XP install disk images that I am comparing, say 650MB each. But all the BC4 needs to read is the NTFS directories.)

4. Should there be a message in the green area something like "comparison loaded in x.xx seconds"? Or is the "Load Comparison" message the only one to expect? And does it come at the beginning, or after the comparison finishes?

Finally, a couple of minutes after I took this screen shot, the white/clear folders finally became yellow.

Thanks again for the time you've put in on this. Again, to the best of my knowledge and utilities, my XP system and my hardware are operating without any known problems.

[Aaron]

Hello,

The white/blank folders indicate they are still loading, so I would expect the abort button to continue to blink until they all had a color assigned. The Handling tab would have some of your scanning options.

Could you email in your Help menu -> Support dialog; Export -> BCSupport.zip to [email protected] with a link back to this forum thread for our reference?

[jmthomas]

Here's the Handling tab:


I've emailed the BCsupport.zip file. Take you time; others may need your expertise more than I do.

[Aaron]

Thanks.

I found the issue. You have customized your colors in the Tools menu -> Options dialog, Colors/Fonts section, "Color folders to reflect content" is disabled. Please re-enable this option to have the folders color with the status of the content within them.

[jmthomas]

DUH! (Slaps forehead) I should have found that. Sorry to bother.

Thanks!