Compare failure "different type" when duplicating

[propeller]

I've just bought a 1TB networked HD and am trying to copy files from smaller drive using the duplicate feature in retrospect. There are a lot of files failing the compare test, resulting in line entries on the log similar to this example:

 

 

Sorry for using an image but the little circle symbols shown on the source file are the problem...

 

The files in question do seem to have copied but I'm reluctant to wipe my originals with so many errors created during duplication.

 

Does anyone know how pass the comparison test or maybe just put my mind at rest about trusting the process.

 

I'm using Retrospect 6.1.126 on Mac OSX 10.4.9

[Lennart_T]

How do you mount the network drive?

AFP is the right way: It preserves Mac specific file info.

SMB is the wrong way: It destroys Mac specific file info.

 

If you files are cross platform, this doesn't matter. If they all are JPEG you are fine anyway.

 

http://en.wikipedia.org/wiki/Creator_code

 

See Mac OS types here:

http://en.wikipedia.org/wiki/File_format

[CallMeDave]

Dealing with networked shares can introduce various issues with Retrospect unde OSX. You don't provide any deatails about the file sharing protocol of your new network device, which might be helpful to know.

 

iPhoto does not assign Type/Creator codes to its files, so the fact that the file type of your Source (src) files are null is to be expected. Somehow, however, these files are being assigned a file type on the Destination. Retrospect is not doing this, so either some utility on your machine or something about the NAS is adding the metadata.

 

I would test using just the Finder, by doing a drag copy of a file without type/creator codes (but with a proper file extension in the name) and seeing if the resulting copied file has been assigned a type or creator code.

 

I don't know the correct terminal commands to reveal this Macintosh data (Russ?); I use a very helpful contextual menu called "FileUtilsCM"

 

http://www.abracode.com/free/cmworkshop/file_utils.html

 

Since Retrospect uses the same API to Duplicate files that the Finder uses, I would expect that the same thing will happen. If so, it's probably a feature, not a bug, of something you are running.

 

 

Dave

[rhwalker]

Terminal commands depend on whether these files have OS 9 metadata, or whether the creating utility provided a resource fork so that Classic programs could use the files.

 

The command for OS X metadata is "mdls". See "man mdls" in Terminal.

 

By the way, if you are ever trying to figure out the appropriate command for something, the magic command is "apropos" - i.e., "apropos metadata"

 

Russ

[propeller]

It feels like I'm getting in very deep - very fast. Thanks to you both for the speedy replies.

 

I am using afp:// (is this the file sharing protocol?) as the prefix to the IP address in the "connect to server" dialogue. Most of the affected files are .jpeg but not exclusively.

 

Having never looked into type/creator codes I can't be sure I'm responding correctly to your comments (CallMeDave), but I downloaded that nice bit of software and can now see what you mean.

 

Having tested by dragging and dropping a test file which I know has no type or creator information I can say that there was no new data added by the finder when the file was transferred to the networked disk.

 

However the same test file when duplicated by retrospect did have new type and creator data added. The file now has the correct type information, but thinks its creator is 'ogle'. This string appears to be random as other tests result in different strings of letters.

 

I can see how this would produce a discrepancy for retrospect but don't know how to solve it.

 

If this sheds any light and you can shine it back at me without dazzling me in technicalities I'd be very grateful.

 

Chris

[rhwalker]

One possibility to consider in order to finesse all of this would be to do the duplicate of these JPEG files back in the reverse order, providing you are comfortable with the data in the files. That would put the "added" metadata on the old files, and make things match on both sides, allowing future backups / duplicates to proceed smoothly.

 

Just food for thought.

 

Russ

[CallMeDave]

I just did a test Duplicate of an iPhoto file (without type/creator codes) to an AFP volume (from OS X Server). No errors in the log, and duplicated file also has no metadata.

 

Something is assigning the codes, based on the name. "ogel" is the creator code for the old PictureViewer application, which sounds like whatever is doing it is somewhat out of date.

 

What you are seeing is odd, but not harmful. There have been lots of utilities over the years to map creator codes and types to/from file names/extensions. It won't change the pixels in the jpeg.

 

You might try the same test duplicating the same sample file(s) to a different Destination volume then this network device (what is the make/model of the device you are using?). You can setup a file on any volume, making sure to define it as a Subvolume in Retrospect, and use that a a Destination (a Duplicate can erase existing files, so choose your Destination carefully!!!).

 

Dave

[propeller]

Who'd have thought transferring data would be this tricky?

 

Before turning to Retrospect I tried just dragging and dropping the source folder to the new drive but the copying process stopped when one file had an error.

 

 

Thanks Dave - I tried the test duplicate to another volume and it worked without adding metadata implicating the new drive, although I did successfully back-up and restore files to it last night. (the restored files do not have metadata added).

 

Also - thanks Russ. I understand the idea about re-duplicating back to source with the amended files but as my original source is 3GB bigger than my destination folder I suspect I do not have a reliable duplicate.

 

I've sent a support request to LaCie to see if they have a view (my new drive is a 1TB LaCie Ethernet Big Disk).

 

I'm still stumped, but an increasing number of other application crashes, including retrospect (which I have never known to crash before), is leading me to suspect the new drive and I will be taking it off line for a while whilst I look for solutions and try to put some bread on the table.

 

Thanks for all the help - any ideas still gratefully accepted but maybe good ol' Retrospect 'aint the problem.