I tested restoring a few files on a drive that recently developed some bad blocks (yes will be replacing that drive shortly :)). But the restore failed because Duplicati, I think, kept trying to restore the file to the same location rather than noticing there was a bad block somewhere there and writing around it.
As bad blocks can occur on non-failing drives, it seems that the file patching should be written to a valid block rather than failing the entire restore. Because, in the end, I didn’t get my file restored which defeats the purpose I think. Thanks.
From the log:
Warning: Failed to patch file: “xxx”, message: The file or directory is corrupted and unreadable.
, message: The file or directory is corrupted and unreadable.
System.IO.IOException: The file or directory is corrupted and unreadable.
That defeats the purpose. The point is I have a ton of room left on the drive so Duplicati and I shouldn’t have to create a new directory, restore a file, then move it to the old directory. Rather, Duplicati should detect the bad black and simply use a working block upon restore, the same way normal copy/paste works where, if Windows or Linux or whatever, encounter a bad block upon pasting, the OS works around it rather than failing the entire operation.
The main point of trying restoring to a separate location would be to verify whether or not you continue experiencing the same error. If the error goes away then your hypothesis would be correct (and you have a usable workaround while the Duplicati developers look into the issue). If the error persists for some reason, then the root cause would most likely not be what you assume. Either way this is the first troubleshooting step that should be done IMHO.
I’m aware of how to check for bad blocks. My post was that Duplicati, on restoring a file where the block had been marked as bad, was failing the restore rather than simply writing the restored file to a different block.
Computers don’t work like that. Folders don’t correlate to sectors. You can overwrite the same file repeatedly and it will write to different sectors on the drive every time. Bad sectors are detected by the drive’s controller (the circuit board built into your drive), and reallocated there without even telling windows if possible. If the drive controller can’t do that for some reason, it passes an error to the bios/uefi (motherboard), which forwards the error to the operating system kernel (windows/linux/etc), which passes the error along to the application that was trying to write to the disk (duplicati), and then the application would be responsible for displaying the error to the user, or automatically trying to handle the error by attempting to write the file again, but the application isn’t responsible for specifying which sector to write to. Running chkdsk c: /r will cause windows to locate all bad sectors and mark them as bad in the partition so it won’t try to use them again. It would be a terrible idea for backup applications like duplicati to do the operating system’s responsibilities. I hope this helps you understand.
Look I’m just reporting what actually happened not what should have happened. The bottom line is that, on a disk with bad blocks but lots of otherwise free space, Duplicati failed a restore with the error I listed above.
Maybe I haven’t been clear: I’m aware of bad blocks and chkdsk etc. I’m reporting a bug in Duplicati. Literally every other Windows application can read and write to that drive and work around the bad blocks. Duplicati can read from it without choking (though it notes the read failures in the log); Duplicati, however, is the only application that is unable to write to the disk during restore. In fact, in order to restore from Duplicati, I had to restore the files to a different disk and then use Windows cut/paste to stick them back on the bad-block disk, which Windows had no problem doing since it just wrote around the bad blocks. Duplicati, on the other hand, choked when doing essentially the same task.
I’m reporting a bug, not asking for help about how to deal with failing drives.
This is the part where you’re misunderstanding. Windows applications themselves don’t work around bad blocks. That is the responsibility of the OS and/or hard drive.
It was pure luck/chance that Duplicati was the application that hit those bad areas of your hard disk. If any other program happened to try and write data to that location, it too would have failed.
Any guesses as to a reason behind @mobamoba’s seemingly consistent test results? I admit that if I got an outcome as clear as the one he reported, I’d be thinking twice about whether it’s some issue inherent to Duplicati.
I’m saying that’s not the case which is why I took the time to report this. Duplicati chokes on restoring a file whereas Windows copy/pasting the exact same file to the exact same directory on the exact same drive doesn’t.
No, it has marked them bad. The way I knew I had bad blocks, before I even posted here, is that I ran a chkdsk /R which marked the blocks as bad and remapped them. Later, I went into Duplicati to restore a few files which had been on the bad blocks.
That’s where I got the Duplicati error above where it couldn’t restore - after the disk had been fully scanned and bad blocks marked.
Sounds like you still have sectors that aren’t quite 100% but are not yet marked as bad.
If a sector is marked bad by Windows (NTFS) then it won’t be used.
The mfr diagnostic utility may be better than chkdsk /r in this situation.
But honestly i’d probably plan to replace the drive if it were me.