Restore: Error -1012 (feature unsupported)

[Tree]

I've just been performing some restorations of data, as a coworker's computer was fried during a recent power outage. I'm setting him up as a user on another spare machine, and after creating the folders to correspond to what I intended to restore and defining them as favorites, I tried to restore the backed-up version of those folders into the new location. I selected the "overwrite corresponding files" option, though the brand new folder was completely empty, so there wouldn't be anything to overwrite.

 

What happened was that I got a large number of execution errors, 190 of them saying "error -1012 ( feature unsupported)", almost all of these for files named "Icon" but a handful for actual files like Word docs. This is out of a total of 2,455 files; other similar files like those Word docs were restored into the same exact subfolder, and those files open up readily as expected.

 

What does this error mean? I figure that for the "Icon" files I can live without them, but the real DOCs need to be restored. I can try running the restore again, though perhaps with a different option selected so as not to overwrite things.

 

I guess it might be pertinent, too, that I had other things going on at the time, competing for network bandwidth; the machine that the Console and Engine are installed on was in the middle of downloading the new Retrospect update installer. I'm running on build 525/526 for the moment - I'll be updating once I finish downloading 626.

[Tree]

Okay, after running the same script a second time but this time with the destination option set to "restore only missing files", I got it to successfully restore all but ONE of the Word Docs... and it still gave the same error for all the Icon files. In other words, 172 errors this time around; 171 "Icons" not restored, plus 1 .DOC file. I'll go ahead and run it one more time to try to nab that last file, but I'd still like to know what is going on here.

 

Specifically, this is what a single entry (of the 172) in the Log looks like:

 

*File "HD-JMG/Users/username/Public/OPEN-JMG/JMG/0000-BaseCMFolder copy/0000-Void/Icon": can't duplicate to "HD-JMG/Users/username/Public/OPEN-JMG/JMG/NewBaptistWV/0000-Void/Icon", error -1012 ( feature unsupported)

[rhwalker]

It would be interesting to repeat the test with build 626.

 

Other useful information would be the version of Mac OS on the machine running Retrospect (and its architecture - PPC or Intel), as well as information about the client (client version, Mac OS version, architecture).

 

You might also try putting the client machine into Target Disk Mode ("TDM") and trying to restore as a local destination Firewire drive. That would eliminate client issues.

 

Russ

[Tree]

I ran this restore once again last night, prior to updating to 626, and did manage to get the last "real" file, so I went home at that point. This morning, I installed the 626 Console and Engine, and re-ran the same restore ("restore only missing files" still).

 

My error count has gone down, but not by much. It was 165 errors this time; the four times I have run the script, it has gone from 190 to 172 to 168 to 165. These were all "ICON" files so I don't need to recover them; from this point on they're just helping to test/discover what is going on.

 

The engine and console are installed on an Intel iMac, 2.8 GHz Core 2 Duo, running OS 10.5.8, with 2 GB DDR-2 800 MHz SDRAM. Communicating with client across hardwired Ethernet LAN. Client is on a 2.1 GHz Core 2 Duo running OS 10.4.11, with 1 GB DDR-2 667 MHz SDRAM.

 

One other variable I think might be pertinent: the hard drive name. I've noticed before that if I change the name of the hard drive at a client machine, then in the Console none of the previously defined favorites work anymore, nor can I define new favorites because the root-level instance of the volume doesn't show up under its new name. I haven't figured out a way to get around this, so in this case I left the name of the hard drive what it was. This means that it is restoring the contents of "HD-AAA/samepath/OPEN-AAA/" to a new location "HD-BBB/samepath/OPEN-AAA/". As mentioned before, it did in fact restore over 90% without issues the first time around, so the destination volume name did not trip it up. But I do notice that the error messages say that they could not duplicate to "HD-AAA/samepath/OPEN-AAA/". Is there anything to this?

 

Incidentally, I purposefully renamed hard drives a long time back so that I could distinguish amongst them, rather than having an office full of "Macintosh HD's" - it comes in handy when mounting network volumes.

 

EDIT: Client version is 6.3.023

Edited November 11, 2009 by Guest

[rhwalker]

I've noticed before that if I change the name of the hard drive at a client machine, then in the Console none of the previously defined favorites work anymore, nor can I define new favorites because the root-level instance of the volume doesn't show up under its new name.

That's the expected behavior because the old source no longer exists.

 

You have to respecify the source.

 

Russ

[Tree]

That's the expected behavior because the old source no longer exists.

 

You have to respecify the source.

 

Russ

 

I understand that, I just wish there was a way to rename a volume and still have Retrospect remember the favorites that were already defined on that volume. Even if it has to be done via the Console (i.e. renaming a volume via Finder at the client machine might still cause trouble), I'd accept that. But there are buttons that could be full of potential, labeled "Rename" and "Locate", which get greyed out when you select the Volume name. They're there for another purpose, I know, but it would be GREAT if at least one of these actually had some functionality when the Volume is selected in Sources, so that one could effectively migrate a bunch of defined favorites over to a new or renamed Volume.

 

Still, this is a tangential issue; I just brought it into play because it might have bearing on the error messages.

 

[rhwalker]

Oh, I agree with you that the handling of renamed / reformatted / cloned, etc., volumes could be handled much better, even if there just were some way to say %*^#$@, this is really the same volume as before, treat it that way.

 

As for the .icon issue, does EVERY .icon file have this issue or just some? Anything funny about the metadata for those files (mdls)? Owner, permissions, etc.?

 

I'd suggest submitting some of those files in a .zip archive to EMC Retrospect support to investigate this bug.

 

Russ

Edited November 11, 2009 by Guest

[Tree]

I would say that it is just some and not all, as the 3rd attempt had 168 errors all ICONs, yet the 4th attempt had only 165 errors, meaning at least 3 ICONs were restored correctly. There may have been more such files in the total of 2400+ files that were initially to be restored.

 

I spoke with the user of that computer and he did recall coming across these little vestigial files, which he resorted to manually deleting when he could. Thus, it appears that they are something akin to orphaned aliases perhaps, that never should have been there to begin with, as he doesn't even know how they were created. Retrospect had done its due diligence to back them up, but the errors on restore seem to have a purging effect.

 

So I'm not sure this is really a bug per se; the bug may have been in the initial creation of all these ICON files, by some other piece of software. Although, the fact that I had to re-run the restore in order to get a few bona-fide files maybe still points to a bug in Retrospect.

 

I don't know how to get those ICON files into a ZIP, since I cannot restore them and the original computer they were on is kaput. I guess I could send the Media Set which has them backed up.

[rhwalker]

Hmm.... I'm wondering if they might not be a vestige of pasting custom icons into a "Get Info" window? Perhaps Retrospect 8 doesn't handle those correctly.

 

Perhaps even in Mac OS Classic? My brain is old, I don't recall if the format of .Icon files changed from Classic to OS X.

 

But I do seem to recall something funny about them, perhaps that they had only a resource fork and no data fork. That could make Retrospect 8, with its Windows heritage, choke.

 

Russ

Edited November 11, 2009 by Guest

[Tree]

I just did another test, this time restoring into a new folder on a local volume rather than to the client. The restore proceeded error-free, 2,455 files. As I pay attention to the error log on the earlier attempts, I notice that it's reporting that the file ".../pathA/Icon" cannot be duplicated to ".../pathB/Icon", and then further entries are that ".../pathA/Icon" cannot be duplicated to ".../pathC/Icon" and so on. In other words, it was somehow seeing the Icon sitting in Path A as being the same file as the Icon sitting in Paths B, C, D, etc. In fact, scanning through the log I see only 3 original files, which are failing to be duplicated to a total of 165 locations, and none of the 165 is the same path as the original.

 

Here's where it gets really odd...

 

I look carefully at the logs from the previous attempts, and it is not the same 3 originals failing to the same 165 locations (actually more locations in previous attempts). In fact, in the next most recent attempt, it is 3 completely different originals that are failing to be duplicate to 168 locations, and among these target locations are included the 3 originals that show up in the subsequent attempt.

 

It's hard to describe, but this is what I am seeing: each successive attempt has 3 fewer errors (considering only the Icon files now). On the second attempt (I didn't check the log for the first since it included so many non-Icon files), there were 3 originals that failed, call them A, B, and C. A failed to duplicate to 14 locations, including D. B failed to duplicate to 13 locations, including E. C failed to duplicate to 144 locations, including F.

 

On the third attempt, there were 3 originals again that failed, but these are D, E, and F. D failed to duplicate to 13 locations, including G. E failed to duplicate to 12 locations, including H. F failed to duplicate to 143 locations, including J.

 

On the fourth attempt, there were 3 originals again that failed, but these are G, H, and J. G failed to duplicate to 12 locations. H failed to duplicate to 11 locations. J failed to duplicate to 142 locations.

 

Yet, as mentioned before, this exact same snapshot did restore perfectly fine to a local volume, in a new folder.

 

EDIT: I should mention, as well, that the first entry in the log for each failure of an original is what becomes the original for the next attempt... i.e. D is actually the first location that A failed to duplicate to, and G is the first location that D failed to duplicate to.

Edited November 11, 2009 by Guest

[rhwalker]

Ok. Sounds like you have a good test case for the bug. You might try zipping the 3 originals in a file, attaching so that the Retrospect bug squashers could investigate.

 

Good sleuthing.

 

Russ

[Tree]

This is what one of the restored ICON files looks like on my local volume, examined using Terminal "ls -l" command:

 

-rwxrwxr-x@ 1 michael admin 0 Feb 10 2000 Icon?

 

I'm not sure what the "?" in the filename means. But other folders (newer ones) do not include an "Icon?" file.

 

Edited November 11, 2009 by Guest

[rhwalker]

The ? indicates that there is an unprintable character (I would bet that it's a trailing space) in the file name. See man ls for the -q option, which is the default when running Terminal.

man page for ls(1)

 

Also note that the @ after the permissions indicates that there are "extended attributes" (again, see man page). This may be causing Retrospect 8 to barf.

 

It would be interesting to see the output of:

mdls Icon*

 

Here's what I get on such a file at this end (had to go into some dark corners to find this):

 

rhwimac:/Applications (Mac OS 9)/Outlook Express 5.0.6 rhwalker$ mdls Icon*
-------------
kMDItemAttributeChangeDate = 1969-12-31 18:00:00 -0600
kMDItemFSContentChangeDate = 2000-03-22 14:11:12 -0600
kMDItemFSCreationDate      = 2000-03-22 14:11:10 -0600
kMDItemFSCreatorCode       = 1381188932
kMDItemFSFinderFlags       = 17408
kMDItemFSInvisible         = 1
kMDItemFSIsExtensionHidden = 0
kMDItemFSLabel             = 0
kMDItemFSName              = "Icon "
kMDItemFSNodeCount         = 0
kMDItemFSOwnerGroupID      = 0
kMDItemFSOwnerUserID       = 501
kMDItemFSSize              = 9260
kMDItemFSTypeCode          = 1920168547
kMDItemID                  = 101549
kMDItemLastUsedDate        = 2000-03-22 14:11:12 -0600
kMDItemUsedDates           = (2000-03-22 14:11:12 -0600)
rhwimac:/Applications (Mac OS 9)/Outlook Express 5.0.6 rhwalker$ 

Russ

Edited November 11, 2009 by Guest