A synchronization between the local file system and a file system presented by a file system plug in is possible.byblo wrote:Personally, I'll need the CRC check also on the synchronization tool ...
Regards
Holger
Moderators: white, Hacker, petermad, Stefan2
May i ask you what SMART monitoring tool you are using that does not deliver any warning?knnknn wrote:There was NO NOTIFICATION whatsoever.
Once again, it seems you are using this faulty hardware not only for copying and moving(Backup), but also in combination with another program like player or so.knnknn wrote:In my experience there are hardly ever read errors because a system with read errors is unstable (crashes, audio glitches etc)
What?HolgerK wrote:A synchronization between the local file system and a file system presented by a file system plug in is possible.byblo wrote:Personally, I'll need the CRC check also on the synchronization tool ...
S.M.A.R.T. is mainly about the HDD itself (Self-Monitoring, Analysis, and Reporting Technology).HolgerK wrote:May i ask you what SMART monitoring tool you are using that does not deliver any warning?knnknn wrote:There was NO NOTIFICATION whatsoever.
I'm interested in getting some concrete user experience about the usefulness of SMART or other hardware monitoring tools which claimed to work but don't?
Well... a lot of things can corrupt a file, viruses, badly programmed application, defective hardware, playing with matches in your room, supernovae explosion, aliens attack, whatever.HolgerK wrote:Once again, it seems you are using this faulty hardware not only for copying and moving(Backup), but also in combination with another program like player or so.
Any (in my opinion false) security feeling added by a verify after copy from TC (or any other tool) is obsolete if you use only one single program that may modify data on your disk (this may be a program that changes meta data or simply the disk de-fragmentation task from your OS).
Only a dedicated additional file like a SHA, or MD5 would warn you in this case, and this warning will only happen if you check the consistency of your data before every use (also if you read the data outside TC).
Besides of this: your data will be nuked anyway in this case.
Holger
A file system plug-in can simply show the real file system.byblo wrote:What?
This was a question to knnknn who stated that a interrupted power supply of his internal HD was causing his last problem.S.M.A.R.T. is mainly about the HD..
No i don't miss the point but I'm truly in doubt that implementing such a feature would help you in normal file operations.But it seems you are missing the point from this topic, which here is that we are requesting for an automated CRC check during the moving/copying files process, nothing else.
Nope, it's an statement of fact. Can't you tell the difference? And I'd get that cough seen to soonest - it might be swine flu.Is that what you called *cough* an argument?
He answered that CRC calculation is impossible with the default copy method. That's all. He could never claim that CRC is impossible per se, BECAUSE OTHER FILE COPIERS ALREADY HAVE CRC checks.
Oh dear, that does sound like a faulty power supply to me. Have you had it checked?Years ago I also did not SEEM to have copy errors until I found that for months my LAN transfers had been corrupted.
How unfortunate for you. Strange that no one else here has reported having their data corrupted by these evil gremlins as far as we know. Odd that MS isn't being crucified by 100s of millions of irate Explorer users who have lost their data through it also having no auto copy validation function. Could it possibly, just possibly mind you, be YOUR rubbish equipment that is at fault and not TC's shortcomings, do you think?That was just one of my examples. I encountered all kinds of copy errors for all kinds of reasons.
Google with their thousands of HDDs posted their SMART experience. SMART is basically useless.HolgerK wrote:I'm interested in getting some concrete user experience about the usefulness of SMART or other hardware monitoring tools which claimed to work but don't?
I am not using any faulty hardware. I am not using any player in combination with copying.HolgerK wrote:Once again, it seems you are using this faulty hardware not only for copying and moving(Backup), but also in combination with another program like player or so.knnknn wrote:In my experience there are hardly ever read errors because a system with read errors is unstable (crashes, audio glitches etc)
CRC doesn't give FALSE SECURITY, it gives INCREASED security because it can and DOES catch copy errors. Nobody claims that it is perfect but it saved me from data loss a lot of times.HolgerK wrote:Any (in my opinion false) security feeling added by a verify after copy from TC
There is nothing to DOUBT. I am using already alternative file copiers (TeraCopy, FastCopy) and they DID catch copy errors.HolgerK wrote:No i don't miss the point but I'm truly in doubt that implementing such a feature would help you in normal file operations.
There is nothing to "compare by content" if you MOVED the file and now it is corrupted.HolgerK wrote:In my opinion this is what you should do once with new or unknown hardware or in regular intervals like an inspection.
And you can do it already using "Checksum calculation/verification" or "Synchronize directories : compare by content".
Yes, this would be great if TC would offer such a function: Calculate the checksums and store them centrally and then optionally compare with every copy/move. But this is already a step too far. Let's first start with a simple "Verify after Copy"HolgerK wrote:In normal file system operation a dedicated md5 or sha file (which may be handled automatically by TC as durable per file information just like the description comments) is something that would help more users in most cases.
I just wanted to answer your post. But then I realized... I don't have to.SQUIRE wrote:Nope, it's an statement of fact. Can't you tell the difference? And I'd get that cough seen to soonest - it might be swine flu.
So you were told that your fetish was infeasible by TC's author. Nevertheless that has not prevented you from insisting that Ghisler accommodate your demands. So based on unreliable evidence from someone's faulty PC he would have to redesign the current system. And you claim, "how would an OPTION be overkill?" ROFLMAO.
Oh dear, that does sound like a faulty power supply to me. Have you had it checked?
How unfortunate for you. Strange that no one else here has reported having their data corrupted by these evil gremlins as far as we know. Odd that MS isn't being crucified by 100s of millions of irate Explorer users who have lost their data through it also having no auto copy validation function. Could it possibly, just possibly mind you, be YOUR rubbish equipment that is at fault and not TC's shortcomings, do you think?
So now that you've replaced your PSU with a hopefully bigger and better one, are you STILL suffering from 'all kinds of copy errors for all kinds of reasons' ??? Are Teracopy and 'other file copiers' still flagging up CRC errors that bad old TC allows through unscathed? Yes? Then show Ghisler your incontrovertible proof. No? Then you don't have a logical leg to stand on, do you?
It's not perfect, it disqualifies non-programmers and won't work with plugins, but it's closest to usable solution so far.MVV wrote:I think here will be good another helper DLL, which will have a function BOOL CompareFiles(LPCTSTR name1, LPCTSTR name2), which will be called after each file copy operation. So, if user don't need verifying and this DLL, TC won't call this function.
You are refering this?knnknn wrote:Google with their thousands of HDDs posted their SMART experience. SMART is basically useless.
You know the difference between prediction and detection?labs.google.com::disk_failures.pdf wrote:Our analysis identifies several parameters from the drive’s self monitoring facility (SMART) that correlate highly with failures.
Despite this high correlation, we conclude that models based on SMART parameters alone are unlikely to be useful for predicting individual drive failures. Surprisingly, we found that temperature and activity levels were much less correlated with drive failures than previously reported.
Hmmh:knnknn wrote:I am not using any faulty hardware.
HolgerK wrote:This was a question to knnknn who stated that a interrupted power supply of his internal HD was causing his last problem.
You should read, understand and quote my complete posting.knnknn wrote:HolgerK wrote:Any (in my opinion false) security feeling added by a verify after copy from TCCRC doesn't give FALSE SECURITY, it gives INCREASED security because it can and DOES catch copy errors.... (or any other tool) is obsolete if you use only one single program that may modify data on your disk (this may be a program that changes meta data or simply the disk de-fragmentation task from your OS).
It's a wrong feeling because the verification only states that the copy may be successful, but not that the data are the same after 1min, 1h, 1d, 1w, 1m, 1y,..HolgerK wrote:For most users nothing else than a wrong feeling like "my files are stored secure" while the statement "my file is copied secure" may already be wrong because of file system caching effects.
My doubt was not about the ability of specialized tools in detecting a faulty copy, but more about the usefulness of such a feature if in normal every day use no copy error comes up, which seems to be not in your case.knnknn wrote:There is nothing to DOUBT. I am using already alternative file copiers (TeraCopy, FastCopy) and they DID catch copy errors.
Um, not quite so convenient unfortunately. If there were 1000 instances of the name 'Hacker' in the input from your file, the checksum will usually catch the change of one of them to 'Hucker'. However, if I were to change all 1000 of them to 'Hucker' it is entirely possible for the hash algorithm to calculate the same checksum as it would have for the unaltered data because there will mathematically always be many different data inputs that resolve to that same checksum. Hash collisions if you'd like to look at it that way. For the same reason it is actually quite trivial to alter data to fit a particular CRC if you want i.e. a CRC is no guarantee of absolute data integrity. CRCs are only good at detecting error conditions when the number of bit errors is relatively low.Well, for that to happen two exactly opposite mistakes would have to happen. For instance in a 1 GB file if a bit is changed on a certain position during copy, then the same bit would have to be changed back during read from target...
I repeat, what gives you the confidence to make that assertion, especially with a fault that can affect every single subsystem in that machine at any time to any degree of severity?That a faulty PSU (or faulty RAM, or faulty HDD, or overheating CPU, or anything else) would cause mistakes at the exactly same position at two different specific times twice is highly improbable...
Please remember that you are on an intermittently failing PC. You could never point to any data on that machine and assume anything, least of all that this is 'good' and that is 'bad' data. All data has now to be treated with suspicion because both your source and target drives are at the mercy of the same flaky PSU. That much is bleeding obvious in knnknn's plaintive cry:Assuming we are talking about creating a CRC from the target data, which we assume is a bad copy of the original data, then we either get correct CRC from bad data, thus not matching the CRC from good data, or we get wrong CRC from bad data, again, not matching the CRC from the good data.
And I might add, one cannot even dare claim that this particular CRC is 'correct' and that one is 'incorrect' whichever software program created it, be it TC or Teracopy, because you're calculating and comparing them on a potentially shaky platform. Until the problem component is replaced, you really cannot know if anything you're getting is valid or not. Is it somehow still not clear that anyone putting his faith in a validation tool on this machine under these conditions is living in a fool's paradise?And usually there are no CRC errors when you copy from (S)ATA-harddisk to (S)ATA-harddisk WITHIN THE SAME PC.
But this was the first time that a whole file became COMPLETELY unusable. It was ESPECIALLY strange since it was within the same PC.
But, you are dismissing hash functions as a means to verify data integrity entirely. I think any good hashing function can be used for the purpose of verifying data integrity. (SHA256 > MD5 > CRC32)if I were to change all 1000 of them to 'Hucker' it is entirely possible for the hash algorithm to calculate the same checksum as it would have for the unaltered data because there will mathematically always be many different data inputs that resolve to that same checksum. Hash collisions if you'd like to look at it that way.
Exactly that - uncertainty. You are saying both that there are a million possible outcomes and that it is probable that the outcomes will be identical. I am saying a failing system will give lots of errors (for instance incorrect checksums) rather than appear completely normal.what gives you the confidence to make that assertion, especially with a fault that can affect every single subsystem in that machine at any time to any degree of severity?
Yes, but that absolutely does not matter. The question is - do the two data sets equal on a failing system or do they not?You could never point to any data on that machine and assume anything, least of all that this is 'good' and that is 'bad' data.
I guess I really do not understand. Are you saying that on a failing system, with data highly susceptible to corruption, everything would start failing except for the hashing functions, which would always show that the data matches the hash?one cannot even dare claim that this particular CRC is 'correct' and that one is 'incorrect' whichever software program created it, be it TC or Teracopy, because you're calculating and comparing them on a potentially shaky platform.