_Shorty

Perhaps it is a language/communication issue. You seem to be saying specifically not to worry if it reports errors because errors are ok.

Do you honestly not recognize how silly this response is? The whole point of the util is to inform you of hash mismatches if there ever is one, because a hash mismatch means you now have a corrupt file that you need to deal with. You're saying to ignore hash mismatch reports because they mean nothing and everything is actually fine. Perhaps you should take the weekend and think about why this is ridiculous to say.

Are you supposing that a file that is a mere 2945 bytes was somehow hashed by the util before it completed writing and that's why the hash was incorrect? Heh. I sincerely doubt that. Saying "A file's hash is different if you hash only a portion of the file." is kind of a silly thing to say. Of course it is going to give a different hash. It is different data. I'd be incredibly surprised if we were talking about incomplete files being hashed, espectially given my initial report involving just 2945 bytes of data. By your own admission, the util does not function correctly. No point trying to defend it by saying it is mostly ok a lot of the time. This is something that is supposed to be 100% correct 100% of the time. If it is not, there's no point in using it.

Well, in my case, nothing uses any of my shares directly except for Kodi accessing files for playback. All files that are copied to the unRAID box are either copied there manually, or backed up occasionally via a scheduled robocopy. The file in question in the screenshot I posted way back then is an image file that belongs to a game. It would have been copied over to the unRAID box once and never changed. Nothing would have updated it. Nothing would have edited it. And after initially being put there by robocopy, robocopy would not have put it there again or touched it in any way that I'm aware of. It is a file that the game devs did not change, so there would be no reason for it to be updated during one of those backup runs. I could be wrong, but I see no reason for a false positive other than something within this util itself, because as far as I'm aware the file was copied to unRAID once and never touched again.

Well, I first posted about this when I saw it happening to me back in June of 2018 here: And I'm not the only one that has posted in this thread reporting that this is happening on their machines. I don't think anyone wants to know that some random percentage of their files are probably ok. Seems to me the whole point to begin with is to be able to trust that 100% of your files are ok if it reports that they are, and if there happen to actually be files that are not ok then they should be reported as not being ok. But if it is falsely reporting hash mismatches when a handful of other hashing utils report that the reportedly changed file has not in fact changed at all then that points to the util not operating correctly. And if it is not operating correctly then it can't be trusted. And if it can't be trusted then it fails to meet its goal. I'm rather confused as to how this issue hasn't received any attention in all this time. We're talking over four years of a major bug seemingly being ignored. Perhaps it should get some dev attention so that it can eventually be remedied, and the util then rendered actually useful. I'm afraid it isn't useful while it is not operating correctly. To be fair, perhaps it did receive some dev attention at some point, but apparently it is still exhibiting this flaw, so this would indicate the root of the problem was never actually fixed. Hopefully it will be fixed at some point, because it would be nice to actually be able to use and trust such a thing.

So, is this util still broken and people are still using it? Anyway... If you only have a handful of files you'd like to do this for, just move them somewhere else, and then move them back.

No, Nvidia NIC, if I remember. It's a pretty old AMD system with an Nvidia chipset. AMD Phenom™ II X4 965 CPU, ASUS M3N72-D motherboard with NVIDIA nForce 750a SLI chipset. The CPU and the Realtek 2.5 Gbps were only giving me about 800 Mbps while maxing out one of the cores, haha. So for now I went back to the Nvidia NIC, as it offloads enough from the CPU to max out its 1 Gbps. But at least it is another reason to upgrade that machine to something newer with an NVMe SSD for cache. At least I have a 2.5 Gbps NIC that I know will work if whatever I get doesn't already have a 2.5 Gbps port built in. The Realtek seems to have a larger software component that the old CPU just can't crunch through quickly enough to make it worthwhile to use in that old machine.

I'm happy to say I figured out the issue. For whatever reason something wasn't happy with both the motherboard ethernet and the new NIC installed. I did manage to find an old GPU I could put in the box so I could do some investigating, and the first thing I tried was disabling the onboard ethernet to see if that might be enough. Luckily it was just the ticket. Fired up the machine and it showed 1.0 Gbps at the switch at first, but once the OS started booting and hardware drivers started getting loaded, when it got around to the driver for the NIC the light went out on the switch and shortly afterwards came back on but showed a 2.5 Gbps connection. I'm glad it was as simple as that. Thanks again for your time anyway.

Without a GPU it isn't quite that simple, but thank you for trying to help. I can't remember if I have a spare video card lying around, but if I do I will look further into it. Otherwise I'll just live with it as is for now. Thanks.

Yeah, my new main/gaming rig I built recently has a 2.5 Gbps NIC in the motherboard. I also upgraded my internet service to 1.5 Gbps, and that new modem has four ethernet jacks, but one is a 2.5 Gbps jack, so I figured I might as well get a 2.5 Gbps switch and NIC for the unRAID box and speed up transfers between it and my main box. Now, the unRAID box is headless. (Doesn't even have a GPU in it.) I'm not sure how I can get the diagnostics file off of it to take a look, as with the new NIC installed I can't connect to it. I imagine as soon as I take it out and connect back to the original NIC and fire it up the diagnostics will be overwritten as it is booting up, no? edit: Ah, I see I actually have to run the diagnostics tool to get that info. I can't do that without being able to connect to it over the network. Doh!

Well, I'm sorry to say the card arrived and does not work for some reason. When I power on the box my switch shows that it is connected at 1.0 Gbps and then as the box continues through the boot cycle it eventually stops showing as connected at the switch. The first card I had would still show connected at the switch at 1.0 Gbps, but would never get a network connection in the OS. It's all quite puzzling. Guess I'm stuck with 1.0 Gbps via the motherboard NIC. Oh well. edit: The card looks different than the first one I had, but also looks different than the one in the picture at the link. Newer revision yet again, I suppose. This one's got a heatsink on it.

Have you selected any files/directories to attempt a job yet? They're inaccessible until there's something selected, at which point they become clickable.

Great, I'll snag one. Thanks!

At 2.5 Gbps? I snagged this one the other day, which looks very similar but is perhaps/probably a different revision, and it would only work at 1.0 Gbps. https://www.amazon.ca/gp/product/B08VWQFQ5Z/ I returned it since it did me no good sitting at 1.0 Gbps.

As has been said by more than one user, when this plugin says there are hash errors but external tools say the hashes/files have not changed, you cannot blame anything but this plugin. My server is 100% fine. If it were not, there would be other issues rearing their heads. This plugin incorrectly stating files have changed is a problem with this plugin. Again, I am not the only person that has reported this issue. And it's not like I'm here fuming mad about an issue the dev(s) are unaware of. I'm simply reporting, again, that the plugin does not properly do what it is designed to do. It really does not matter to me at all if it ever works, as the more I think about it there isn't even much purpose to it. Other hash tools report unchanged hashes. Parity does not complain. So is my file actually corrupt because the plugin states it is? Incredibly unlikely. If you take half a dozen hash tools and they all report the same hash, at some point you have to believe the hash is correct. What bothers me is person after person trickling into this thread every now and then reporting, seemingly full of anxiety and in a panic, that their file(s) are being reported as corrupt. When the fact of the matter is their files are more than likely 100% fine, and the plugin simply is malfunctioning. Reporting that it is not functioning correctly for everyone and to not trust it as a result is most certainly constructive.

Sorry, but randomly giving incorrect hash errors on files that haven't changed is not something that I would call working well.

Seems unnecessary to me. I'm sure your drive is taking care of that for you just fine. Not like this tool can be trusted anyway.

Frankly, I would be more inclined to believe you have exactly zero corrupt files, and are simply one of a few of us that are reporting that the plugin doesn't seem to behave properly for. Files don't usually go corrupt on people when simply sitting on a hard drive. The hard drive's electronics work with algorithms designed to detect whether or not a read was successful. They can detect when a read was faulty and the data was corrupt. If you are not seeing the drive reporting that there have been read errors, I would not worry about whether or not your data is corrupt. It likely isn't if no read errors are being reported. For whatever reason, the plugin doesn't seem to be behaving properly for everyone that has tried it. Some of us, perhaps a very small minority, have seen reports of corruption from the plugin, but we also have other hashes from other hashing tools on hand that say the files haven't actually changed. The plugin is saying they have changed, but since the other hashing tools are still reporting the original hashes for those files, it stands to reason that the files have not changed and that something is behaving incorrectly with the plugin. If the other hash tools were giving different results then we might suspect actual file corruption. But with other hash tools still agreeing with previously established hashes, that narrows it down to the plugin being the only one misbehaving. If you're not getting read errors reported from the hard drive, I wouldn't worry about it, and I'd simply uninstall the plugin. It would be nice to have an automated hashing system in place, but if it doesn't seem to be working properly it isn't of much use.

If you read a few of the recent posts it would seem to indicate that your files are likely just fine and the plugin might not be workng properly.

Cache Directories started misbehaving on me a few months back, chewing CPU like crazy after an unknown amount of time, so I stopped using it. I'm not sure if this was because I was stuck on an older version of unRAID or not, but at the time I had not yet figured out how to get my machine to behave with the latest version(s) of unRAID. It is certainly possible that there was some issue with the latest version of the plugin and the older version of unRAID, but which might not exist if unRAID were updated. I haven't tried it again yet to check if the issue is gone now that I'm updated. On the occasions where your machine doesn't sleep is is possible Cache Directories is chewing CPU for you, too?

I would guess so. While it appears it may work correctly most of the time for most everyone, some of us have run into erroneous corrupt file messages, among other things. In my case, the corrupt files still show/match the same hashes with other hash utils, so I'm not sure it's worth bothering with anymore, at least for the moment. Naturally, hard to fix if the dev can't replicate.

Read the last couple of pages.

On the subject of defragging, while it does happen, linux machines tend to avoid fragmentation better than Windows boxes did pre-NTFS. NTFS is better about it than previous filesystems there. Linux filesystems do a pretty good job of avoiding it to begin with, though it is still possible. But, typically, it doesn't happen often enough or to a large enough extent to really worry about defragmenting on linux machines.

Unless you have two parity drives, of course. I wouldn't think the chance of failure while moving files to other drives versus rebuilding would be much different, if at all.

When they fail I replace it and let it rebuild from parity.