Time machine never finishes backup

Hi Jay,

Sounds like another big reason for me to avoid TM, but two solutions seem to be here...

http://www.schollnick.net/wordpress/2009/03/error-12-link-of-previous-volume-fai led-for-dvr-storage/

http://simon.heimlicher.com/hints/macosx/time-machine-volume-uuid

Whew, would you like some far better/far more useful/ far less cantankourous rrecommendations than TM for Backup?

Forget the last time I tried it, but even when it reported no errors... the attempts to restore were less than useful... personally I can't figure out how/why Apple came up with such a Backup APP! 😟

Let me know which way you want to go.

I only graduated from the 6th grade, but the great Pondini seems to have mastered TM, where I have a dozen of more methods of Backup that I can actually rely on...

http://web.me.com/pondini/Time_Machine/Troubleshooting.html

jayquercia wrote:

. . .

CoreEndianFlipData: error -4940 returned for rsrc type FREF (id 130, length 7, native = no)

CoreEndianFlipData: error -4940 returned for rsrc type FREF (id 132, length 7, native = no)

CoreEndianFlipData: error -4940 returned for rsrc type FREF (id 130, length 7, native = no)

CoreEndianFlipData: error -4940 returned for rsrc type FREF (id 130, length 7, native = no)

SystemFlippers: Consumed too much data for FREF ID 129 (pBase = 0x523ce0, p = 0x523d69, pEnd = 0x523ce7)

Those appear to be problems with files from another system, such as Windoze. "Endian" refers to the order in which bytes are stored, which is different on different operating systems. It's also possible they're normal Mac files but so badly corrupted that OSX doesn't really know what they are or what's wrong with them. The fact that you had directory problems might indicate the latter.

These don't stop a backup, though; but could well slow it down while OSX is trying to deal with them. Unfortunately, the message doesn't include the file name, so it's not going to be easy to find them.

Do you recall which disk(s) had directory problems? If so, exclude it/them from backups per #10 in Time Machine - Frequently Asked Questions. If not, try excluding the Design and Media drives.

If the backup runs normally, remove one of the exclusions and try again, to try to narrow the problem down.

jayquercia wrote:

. . .

So I tried excluding all drives and have narrowed the problem down to being with my "Design" drive. As long as that drive is excluded, the others back up fine.

Yay!

I read a few things on other forums saying that since I recently replaced an old external harddrive with a new one with the same name, Time Machine was getting confused

It doesn't get confused, exactly, but since it's a different drive, Time Machine will do a new full backup of it. (On Lion, there's a way to prevent that, but not earlier).

node requires deep traversal:/ reason:kFSEDBEventFlagMustScanSubDirs

I've read that this is because Time Machine doesn't trust that the files on the backup volume and the others are the same. Is there anyway to fix this issue?

It's not a major issue. It means that Time Machine doesn't know whether the previous backup got everything it was supposed to (probably since that backup failed). So instead of using the hidden log of changes that OSX keeps on each drive, Time Machine must compare everything on your internal HD to the backups to figure out what needs to be backed-up. That will take a while longer, of course. But once the backup completes, subsequent backups should be fine.

That's ridiculously slow, and it's still reporting huge file counts and identical sizes from two different volumes. 😟 Otherwise, there aren't any unusual messages in the log.

Try the things in the green box of #D2 of Time Machine - Troubleshooting.

If nothing there helps, your installation of OSX may be damaged. You might want to install the appropriate "combo" update, per Installing the ''combo'' update and/or Reinstalling OSX. If that doesn't help, an Archive and Install will get you a fresh copy of OSX; then apply the "combo" again.

Pondini: Endianness is not about Mac vs Windows. Whether a machine is big-endian or little-endian depends on its processor architecture, not its operating system. Modern Macs and PCs both use Intel processors, which are little-endian.

The error messages jayquercia is reporting looks related to resource forks, which is a legacy (i.e. Mac OS 9) data storage method. There are Carbon APIs for reading these data structures. This particular function, CoreEndianFlipData(), is documented in Endian.h. The error codes are in MacErrors.h:

/* CoreEndian error codes. These can be returned by Flippers. */

enum {errCoreEndianDataTooShortForFormat = -4940,
errCoreEndianDataTooLongForFormat = -4941,
errCoreEndianDataDoesNotMatchFormat = -4942};

1. Don't make stuff up to impress people on the Internet.

2. It is exceptionally unlikely this warning is at all related to backupd's inability to complete a backup.

Paul Schreiber wrote:

Pondini: Endianness is not about Mac vs Windows. Whether a machine is big-endian or little-endian depends on its processor architecture, not its operating system. Modern Macs and PCs both use Intel processors, which are little-endian.. .

Yes, as posted, it's likely something that came from a different system. My abject apologies for not specifying that it could be a different processor.

1. Don't make stuff up to impress people on the Internet.

Kindly get off your high horse.

2. It is exceptionally unlikely this warning is at all related to backupd's inability to complete a backup.

Gee, why didn't I think of that?

Oh, guess what - - I did. From the same post: "These don't stop a backup, though"

Might I suggest a bit more attention to detail on your part, too?