You were right -- the first time

[d-v-c]

Originally you thought the files were bad on my Mac. Then it looked like the NAS wasn't working right. I always wondered how with an error called "I/O" anyone could tell if it was a read or a write error.

Now I'm getting Error #36 errors from the same files that could not be copied by SD. I'm getting strange sounds from my Mac's drive so I expect it is going bad slowly.

IMHO there is no reason to abort a backup because there is an error reading a file. Simply skip the file upon a read error and continue.

Is there anyway to tell SD to keep working even if it encounters errors while backing-up a /USER directory? I can use the log to see what files are bad.

[dnanian]

There isn't any way to tell SD! to ignore errors, no -- sorry. I try to explain why we stop on errors in this post on my blog.

(The error we get, without source/destination information, is from the system -- if you look in your system.log, the device that's failing is listed, and you can match that up with your drives.)

[d-v-c]

"If a significant failure is occurring, steps should be taken to concentrate on recovering your user files, rather than trying to copy the whole drive."

SD should check WHAT the backup was. IF it was a USER backup it obviously need not worry about this issue. All it needs to do ignore errors and continue. (What if there is only one error -- and it is in your first file.) The log provides the user information on what was NOT copied.

If it is a slowly failing drive -- stop and diagnose is silly when there is nothing that a user can do to fix the problem. All one can do is get as many of their USER files backed-up immediately. SD quits exactly when one needs it most!

What I did was manually copy USER files (skipping much of Library) to my NAS. It took days -- because of "file naming" issues -- to do what SD was minutes away from completing.

Please, at least give the user the option of ignoring errors.

Since I have no idea how many non-user files could lie in problem areas -- am I correct that I must replace the drive and lose all applications. I know of no way to "fix" a drive. Smart Reporter claims nothing is wrong!

[dnanian]

There's really no way for us to do that. We don't really know what the files are, what their function is, etc. The user can do things to fix the problem -- for example, check to see what the real issue is, test the file that's being copied, see what's really wrong.

We're not really designed to be a "data salvaging" tool to be used while you're failing -- rather, we're supposed to be used before...

Anyway, I've been thinking about these issues a long time... it's hard to know what the best solution is. But it's not just a matter of "ignoring errors", because users -- when given the chance -- just ignore all errors...

[d-v-c]

Originally Posted by dnanian

The user can do things to fix the problem -- for example, check to see what the real issue is, test the file that's being copied, see what's really wrong.

.., rather, we're supposed to be used before...

Unfortunately, until I ran SD for the first time I had zero indication that there were any problems with my Mac. In fact, the files it claimed were bad -- I could open.

And, the second time I ran SD -- you said the problem was in my NAS which took my attention away from my Mac.

It wasn't until I tried manually copying files that I got an error 36 on one of the same files SD warned about. And, I started hearing bad clicking from the harddisk. So although it sure seems something is bad, it's hard to "fix" without a real indication of exactly what's wrong. SMART still claims there is nothing wrong.

I'll run Disk utility and see if it finds something.

PS: It would be very useful if the SD log clearly noted if the error was read and/or write. Looking in the Sys Log after a fail is not an intuitive way to find out which it is.

[dnanian]

I believe I recommended, after your first copy, that you follow the steps in the User's Guide under Troubleshooting. One of the first things done there is to try to duplicate -- not open -- the files, to see if they're readable on the source. As I recall -- and I don't have the posts/emails handy -- you indicated that they were, which pointed to the destination as the problem...