Jump to content

Error on Verify "File XXXX appears incomplete, path..."


Recommended Posts

To sum things up quickly and give you as much background as I can... our backup machine recently died (hard drive stopped working). I put a new drive into it and installed Leopard. I brought over the preference files from the old machine (with all the Retrospect scripts). Now when it does a duplicate, it successfully makes it through all of the files (doing a "get info" on the file sizes), but when it compares it throws an error (non specific number). It looks like this...

 

File "Source.avi" appears incomplete, path: "Xsan/Client/Source.avi".

 

It throws somewhere around 25,000 errors just like this.

 

Also on a related note, we're doing this for 2 different volumes. The scripts are identical (except for source and destination - both destinations are on the same RAID drive) but the script duplicating the XSAN for some reason changes the permissions on the destination folder to look like a "drop box" (no access).

 

Any thoughts on either of these issues? Help is MUCH appreciated!

 

 

Link to comment
Share on other sites

Ok, the errors are being thrown because the metadata doesn't agree between source and destination.

 

Check your ACL setup, whether you have ACLs enabled for the volume, whether you have propagated them down the filesystem tree, etc.

 

Also, depending on how you set up OD, you may be running with a set of local users, etc., that has different GID and UID than before. Check that.

 

Bottom line - it's a metadata issue caused by differences in ACL setup.

 

Sadly, because of Retrospect's Carbon code base, and an Apple bug in the Carbon API libraries, Retrospect can't back up / restore ACL metadata without causing a crash on Universal Binary MacOS X machines. See the KB article.

 

So you are going to have to recreate your ACL metadata by hand.

 

Russ

Link to comment
Share on other sites

Unfortunately, the issue is specific to an IntelMac, and I'm running this on a PowerPC.

 

Also, I'm running Retrospect 6.1.230

The KB article is wrong. I believe that my statement of the problem was correct. It can happen on any version of Retrospect 6.1.x running on any Universal Binary version of MacOS X with ACLs enabled, on any Universal Binary version of MacOS 10.x.x. MacOS 10.4.x non-server and server on PPC were not Universal Binary, but it was possible to install the Universal Binary version (beginning in 10.4.6) if you knew how to do it, and some did, particularly on MacOS 10.4.x Server, to get around some AFP bugs of Apple.

 

Mac OS 10.4.x PPC (non-Universal Binary) and Mac OS 10.4.x Universal Binary (released only for Intel platform, but possible to install on both) are VERY different animals, built from a different branch on Apple's code tree, even though they have the same 10.4.x version numbers.

 

All Mac OS 10.5.x server and non-server are Universal Binary, and have this Apple bug, regardless of whether you are running on Intel or non-Intel platform.

 

ACLs are enabled by default in MacOS 10.4.x Server, but are not enabled by default in MacOS 10.4.x non-server (but you can enable them using the command line if you know what you are doing).

 

ACLs are enabled by default in MacOS 10.5.x server and non-server.

 

Apple's documents on the behavior of POSIX (non-ACL) permissions under 10.5.x are wrong.

 

This is an Apple bug that causes the crashing, and it is in the Carbon API code. It has nothing to do with Intel or PPC. It has nothing to do with Rosetta.

 

EMC's approach is two-fold:

 

(1) until Apple fixes this bug, which seems unlikely, provide a preference to not back up / restore ACLs so that the bug is not triggered;

 

(2) work on a native (Universal Binary) version of Retrospect that uses the Cocoa APIs, built from a different code base (the Windows code base). That version, "Retrospect X", is announced for beta testing later this year. I am hopeful.

 

Russ

Link to comment
Share on other sites

ACLs are now enabled by default on Leopard workstation, yet it doesn't seem as if there was a big tide of users crashing when it came out. Is it known for sure that the bug still exists in 10.5?

 

Dave

Disabling Retrospect ACL support has fixed this in 10.5.x up through the current (most recent) update. Search these forums for confirmation.

 

Russ

Link to comment
Share on other sites

I turned off the "special" preference to not include ACLS and re-ran the script. It still fails. Any other thoughts? In an effort to save time, I created a new script that's only trying to duplicate a single folder (just so that I don't have to wait 31 hours to see it fail).

You might want to just define a Retrospect "Subvolume" as source and work from that.

 

You might want to use "cmp" in Terminal to compare the files and see whether the bytes in the files are the same or different, and, if they are the same, then move to examination of metadata

(ls -aloe )

 

Russ

Link to comment
Share on other sites

All Mac OS 10.5.x server and non-server are Universal Binary, and have this Apple bug, regardless of whether you are running on Intel or non-Intel platform.

 

Russ, this implies that any Backup done with Retrospect running under Leopard will fail if the default Preference for

"OS X->Do not backup ACLs on Intel machines"

is left unchecked. Is that what you're suggesting?

 

I just successfully backed up an Intel iMac (6.1.230, Source local defined Subvolume, Destination File Backup Set on mounted AFP volume) without telling Retrospect to ignore ACLs, and had no crash.

 

I'm not doing thorough testing here, but I did confirm that at least one file in my Source had extended attributes.

 

My machine started life under 10.4, and Leopard was done as an update (not erase and install). Perhaps that means that I'm not Universal. I don't have a bare metal Leopard install machine to try the same thing with.

Link to comment
Share on other sites

Russ, this implies that any Backup done with Retrospect running under Leopard will fail if the default Preference for

"OS X->Do not backup ACLs on Intel machines"

is left unchecked. Is that what you're suggesting?

Yep, that was what I had been suggesting and was my understanding. Each time I have made that suggestion here in the forums, including to people with 10.5.4, that solved their problem.

 

There may be something more complex here than my simple brain can handle. We are not yet running Leopard because of some OD and AFP issues and also waiting on Retrospect X. We also have one attorney (recently retired) who insisted on using WordPerfect in the Mac Classic environment, and that didn't play well with ACLs (classic ignored ACLs, did whatever it wanted with file modifications), so we stuck with POSIX permissions for his sake.

 

Perhaps my understanding is wrong. Perhaps the issue only happens on certain architectures. You have provided an existence proof that my simple model of the problem is wrong.

 

Are there any propagated ACLs on your source and destination volumes that reach to the files that you backed up?

 

Russ

Link to comment
Share on other sites

Sorry if this is a dumb question, but can you give me what I should type in to do a compare (cmp) in terminal?

cmp file1 file2

 

for a discussion of the options, try

man cmp

 

Here's an example of comparing two simple files that differ in one character:

 

rhwimac:~ rhwalker$ cat foo1.txt
hello, world.
rhwimac:~ rhwalker$ cat foo2.txt
hello, world?
rhwimac:~ rhwalker$ cmp foo1.txt foo2.txt
foo1.txt foo2.txt differ: char 13, line 1
rhwimac:~ rhwalker$ cmp foo1.txt foo1.txt
rhwimac:~ rhwalker$ 

Note that cmp is silent when the files match (as happened above when a file is compared to itself).

 

Russ

Link to comment
Share on other sites

Are there any propagated ACLs on your source and destination volumes that reach to the files that you backed up?

 

I guess I'd have to say no.

 

This is a OS X 10.5 Workstation machine, where I did "Get Info" on a single file, added a user to the existing POSIX information, then in Terminal confirmed that the file was special with the ls -loea command:

 

"0: user:timemachineuser allow read,readattr,readextattr,readsecurity"

 

This file was contained in the Source volume (along with two other extended attributed files); Destination was a File Backup Set with matching disabled.

 

Is it worth it to create some test folders and copy permissions down into them?

 

I recognize that this thread began as a discussion of a Duplicate, but the KB article talks about crash on scanning of Backups.

 

Update:

 

OK, I made a couple of folders, put some stuff in them, added extended ACL permissions to the top level, copied the permissions into enclosing folders, defined the top folder as a Subvolume, and backed it up in Retrospect to a File Backup Set (with Matching returned to its default on state).

Edited by Guest
Additional Tests
Link to comment
Share on other sites

Ok, then it appears my understanding is wrong. Perhaps the ACL issue has been fixed in 10.5.4, and this was a red herring on this particular problem.

 

But it does seem like this is a metadata issue.

 

I wonder if the XSAN in the original problem statement supports the permissions model and timestamp granularity of the source. cmp and ls testing will answer that question.

 

Russ

Link to comment
Share on other sites

Allright, after hours of testing (I wanted to make sure it worked), I've found that Retrospect + Leopard = BAD. I went and reinstalled 10.4 on the machine, used the exact same preference files for Retrospect (that include all of the scripts), and now everything works great.

 

I appreciate all of the help in this matter. For future reference, it might be easier just to tell someone to go back to 10.4 (at least until Retrospect X comes out).

 

Again, many thanks.

Link to comment
Share on other sites

I've found that Retrospect + Leopard = BAD

 

What you've found is that Retrospect + Leopard = BAD on your configuration.

 

You never described the hardware you are using, but perhaps 10.5.x is having issues with the XSan/RAID hardware/software you're using. Without knowing make/model/driver/firmware/etc, there would be no way to track that.

 

Dave

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...