Shirt Pocket Discussions

Shirt Pocket Discussions (http://www.shirt-pocket.com/forums/index.php)
-   General (http://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   TESTING: SuperDuper problems copying some data (http://www.shirt-pocket.com/forums/showthread.php?t=378)

stevea 05-16-2005 01:08 PM

TESTING: SuperDuper problems copying some data
 
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! :mad: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. :mad:

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! :mad:



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 05-16-2005 01:50 PM

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 05-16-2005 03:00 PM

Quote:

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.)


Quote:

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 :mad: => 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 05-16-2005 03:30 PM

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 05-16-2005 03:42 PM

Quote:

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.


Quote:

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.


Quote:

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 05-16-2005 03:50 PM

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 05-16-2005 04:00 PM

Thanks...

ditto copied successfully.
________
MFLB VAPORIZER

dnanian 05-16-2005 04:02 PM

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 05-16-2005 04:07 PM

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 05-16-2005 04:30 PM

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 05-16-2005 04:41 PM

Quote:

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 05-16-2005 04:57 PM

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 05-16-2005 05:49 PM

Quote:

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 05-16-2005 05:55 PM

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 05-16-2005 06:03 PM

Quote:

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?" :D
________
Vaporizer Pipe

stevea 05-16-2005 06:07 PM

Quote:

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

Looks like ditto succeeds:
|04:40:02 PM|Info| WARNING: Source: /Volumes/Macintosh Data/60 GB - OK/Developer/Documentation/Help/QuickTime, lstat(): 0
|04:40:02 PM|Info| WARNING: Target: /Volumes/Hard Drive/60 GB - OK/Developer/Documentation/Help/QuickTime, lstat(): -1
|04:40:02 PM|Info| WARNING: Could not copy file with Cocoa frameworks. Attempting to copy with ditto.

(the log ends there... SuperDuper is still working on the copy, but has proceeded past the problem area.)
________
MOTOR COMPANY ASSEMBLY PLANT

dnanian 05-16-2005 06:08 PM

I know, but I was testing the failure with SuperDuper! I'm working on simulating your case, though... thanks. ;)

dnanian 05-16-2005 06:18 PM

Well, now that's why we have a fallback to ditto: if NSFileManager fails, there's another option.

Interesting: I wonder why NSFileManager fails where ditto succeeds. But I know why it's working here: the filename passed to ditto is quoted with double-quotes. We've reworked that in v2.0, so you won't have to take the double-quotes out of a failed file like this.


All times are GMT -4. The time now is 02:20 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.