TESTING: SuperDuper problems copying some data

[stevea]

I am encountering some problems where SuperDuper will not copy some data.

The data is known to be corrupt, so if you would like I might be able to help you test SuperDuper in this kind of situation.


History:

60GB Maxtor hard drive was corrupting data. (bad, bad Maxtor! Do NOT use Maxtor drives in Macs! My friend's business uses them in Tivo's, where he says they are extremely reliable. But there are lots and lots of Maxtor horror stories on Macs... YMMV.)

I copied data from the Maxtor to a good drive, and verified the data was duplicated correctly.

Some of the data was corrupt, however. (For example, files contained garbage.) There was also some more severe corruption, for example, folder could not be opened.

However, Disk Utilities and DiskWarrior both report the disk and its structure are healthy.

Both the Finder and Synchronize! Pro X can copy the hard drive.

However, SuperDuper cannot copy the drive. It fails and reports this error:

console.log:
Mac OS X Version 10.3.9 (Build 7W98)
2005-05-16 10:21:38 -0500
2005-05-16 10:39:22.797 SuperDuper![500] ***ERROR OCCURRED: ditto: can't get real path for source

SuperDuper!.log:
|10:39:22 AM|Info| WARNING: Caught I/O exception(2): No such file or directory
|10:39:22 AM|Info| WARNING: Source: /Volumes/Macintosh Data/60 GB - "OK"/Developer/Documentation/Help/QuickTime, lstat(): 0
|10:39:22 AM|Info| WARNING: Target: /Volumes/Hard Drive/60 GB - "OK"/Developer/Documentation/Help/QuickTime, lstat(): -1
|10:39:22 AM|Info| WARNING: Could not copy file with Cocoa frameworks. Attempting to copy with ditto.
|10:39:22 AM|Error| ditto: can't get real path for source


Investigating further, it is possible to open the folder "/Volumes/Macintosh Data/60 GB - "OK"/Developer/Documentation/Help/QuickTime" in Finder.

However, the files inside the folder are indeed corrupted.


The corrupted data from the bad Maxtor drive has been the bane of my existence ever since it occurred.

This particular folder is non-essential, but there is other data that is (was) valuable.

The vexing part of the situation is that there are 10's of GB's of data, and thus far it has been impossible to discover which data is good and which data is corrupt.

Thus, I have to continue to store and maintain much more data than necessary, in the event that some of the data is good, although it is uncertain data! Arrggh!



1. Any suggestions how to identify corrupt data here would be most welcome!!! It would be very helpful to be able to effectively separate the wheat from the chaff...

2. If there is anything I can do using this situation to help test SuperDuper!, please let me know how I might be able to help.

3. Note that SuperDuper! cannot copy some files, although those files are easily copied by the Finder. What is wrong here?


Thank you!
________
Honda Spree history

[dnanian]

It's hard to know what could be done here: the difference between what we're doing and what's "working" (in Finder, for example), is that Finder and Synchronize Pro are going to be using Carbon file calls (native to HFS+).

We're using Cocoa calls, which operate with the Unix paths (as does ditto, which is also generating an error). Speaking out of relative ignorance of the HFS+ file system drivers, there might be a wacky mis-mapping between the two layers which is causing a problem. That could explain why Finder can sometimes copy a file that SuperDuper! can't, too.

I don't understand, though, how Finder and Sync Pro can copy the drive if the data's corrupted. They're not copying the drive: they're partially copying the drive, I believe -- no?

This might be a situation where rebuilding the HFS+ catalog would help, or at least be worth a shot. There's a paper about it at the Coriolis Systems site:

http://www.coriolis-systems.com/manu...logRebuild.pdf

(I may have mentioned this to you before.)

[stevea]

Originally Posted by dnanian

I don't understand, though, how Finder and Sync Pro can copy the drive if the data's corrupted. They're not copying the drive: they're partially copying the drive, I believe -- no?

Nope. They are copying everything correctly.

(Of course, the corrupted data files are still corrupted after they are copied.)

Originally Posted by dnanian

This might be a situation where rebuilding the HFS+ catalog would help, or at least be worth a shot.

Nope. As I said, the drive structure was deemed healthy by Disk Utility and DiskWarrior. The catalog is fine and rebuilds with DiskWarrior with no problems.

Maybe it's more clear if I say the "drive data" is flawless, but the good drive contains "corrupted data files". Or, even more precisely, there are good files which contain corrupted data.

Now that that's clear, to confuse things a little- remember the history is the bad Maxtor was indeed a thoroughly-corrupted drive (bad catalog, bad data, piece of garbage, spawn of satan drive), but we are now dealing with the good drive that has the copy of the Maxtor's contents.

Here's what's going on:

evil, bad, corrupted Maxtor => good drive

Now trying to use SuperDuper! to copy (SuperDuper fails, Finder works!):
good drive (with bad Maxtor data) => another drive


Hope this helps...
________
Silver Surfer Vaporizer

[dnanian]

I don't think you can say they're good files, Steve: something's clearly wacky, since they can't be copied with SuperDuper! or ditto (and probably not with cp or other Unix-level tools either).

I did see that Disk Warrior says the catalog is "fine" (though you didn't indicate that you had rebuilt), but maybe fsck does the rebuild differently and might work around the issue.

Try copying a file that won't copy with SD! with ditto and cp, in Terminal (making sure to preserve the resource fork with ditto). Do they work?

[stevea]

Originally Posted by dnanian

I did see that Disk Warrior says the catalog is "fine" (though you didn't indicate that you had rebuilt)

As I said, DiskWarrior rebuilds the disk with no problems. Yes, the disk has been rebuilt.

Originally Posted by dnanian

I don't think you can say they're good files, Steve: something's clearly wacky, since they can't be copied with SuperDuper! or ditto (and probably not with cp or other Unix-level tools either).

In addition to the Finder, Synchronize! Pro X copies the files without problems. Also, Synchronize! Pro X verifies both its own copying and the Finder copying. The Finder copying is perfectly identical to the original.

Originally Posted by dnanian

Try copying a file that won't copy with SD! with ditto and cp, in Terminal (making sure to preserve the resource fork with ditto). Do they work?

I need help to do this, I'm not familiar how to do it.
________
EASY VAPE VAPORIZER

[dnanian]

To copy with ditto and cp, open a Terminal window. Then, issue the command:

sudo ditto -rsrcFork "path-to-source" "path-to-destination"

Your paths have quotes in them, so I've used '' for quoting. For example:

sudo ditto -rsrcFork '/Volumes/Macintosh Data/60 GB - "OK"/Developer/Documentation/Help/QuickTime' '/Volumes/Hard Drive/60 GB - "OK"/Developer/Documentation/Help/QuickTime'

cp would be used the same way, but if you're not under Tiger, it won't preserve resources, so probably isn't a good example. But, the syntax would be:

sudo cp '/Volumes/Macintosh Data/60 GB - "OK"/Developer/Documentation/Help/QuickTime' '/Volumes/Hard Drive/60 GB - "OK"/Developer/Documentation/Help/QuickTime'

[stevea]

Thanks...

ditto copied successfully.
________
MFLB VAPORIZER

[dnanian]

Really! That's strange, because it failed in your log snippet...

|10:39:22 AM|Info| WARNING: Could not copy file with Cocoa frameworks. Attempting to copy with ditto.
|10:39:22 AM|Error| ditto: can't get real path for source

That error is directly from ditto itself...

[stevea]

OK, but that's what's happening.

Maybe SuperDuper is passing a bad argument or something? But FWIW, SuperDuper has copied lots of other items containing quotes with no problems. (Maybe there's a difference between filenames and foldernames with quotes?)

Here's the copy-and-pasted terminal command that worked:
ditto -rsrcFork /Volumes/Macintosh\ Data/60\ GB\ -\ \"OK\"/Developer/Documentation/QuickTime /Volumes/Hard\ Drive/test

In other words:
ditto copy problem folder => test folder on Hard Drive
________
CHEAP SPRING AIRSOFT SNIPER FLASHLIGHT MAGAZIN

[dnanian]

Well, you didn't copy it into the same location it was in the other version: why don't you try that, so the case is exactly the same?

[stevea]

Originally Posted by dnanian

Well, you didn't copy it into the same location it was in the other version: why don't you try that, so the case is exactly the same?

It is successful, also.

ditto -rsrcFork /Volumes/Macintosh\ Data/60\ GB\ -\ \"OK\"/Developer/Documentation/QuickTime /Volumes//Hard\ Drive/60\ GB\ -\ \"OK\"/Developer/Documentation/QuickTime

In other words:
ditto copy problem folder on Macintosh Data => problem folder on Hard Drive

same task as SuperDuper copy:
Macintosh Data => Hard Drive
________
HONDA CBX SERIES

[dnanian]

OK. I can't explain why that's working, Steve, since we did exactly that when the copy failed with the Cocoa frameworks.

Even though it shouldn't matter, let's try removing the quotes from the volume names and running SuperDuper! again.

[stevea]

Originally Posted by dnanian

Even though it shouldn't matter, let's try removing the quotes from the volume names and running SuperDuper! again.

Note- 60GB - "OK" is a foldername on hard drive Macintosh Data- the quotes are in foldernames, not volume names.

Yes, indeed! 60GB - OK is successfully copied by SuperDuper, although 60GB - "OK" fails...
________
Bone disorders advice

[dnanian]

Interesting.

If you look at your log, now, does it look like it retries with ditto and then succeeds, or is there no attempt?

There must be some unusual problem in the Cocoa call we use (NSFileManager) to do the basic copy. I tried the same thing here, though -- naming a file "test file with quotes and spaces" -- and it worked under Tiger, so perhaps Apple fixed it in 10.4.

[stevea]

Originally Posted by dnanian

I tried the same thing here, though -- naming a file "test file with quotes and spaces" -- and it worked under Tiger, so perhaps Apple fixed it in 10.4.

ahem... "Well, you didn't copy it into the same location it was in the other version: why don't you try that, so the case is exactly the same?"
________
Vaporizer Pipe