Disk Utility problem after cloning

[dnanian]

I honestly don't know what's going on here. I can't reproduce the problem at all, and it doesn't make much sense, especially since it happens with everything but CCC, including Disk Utility, and CCC pretty much just copies with "ditto".

We absolutely do not link files that weren't originally links on the main drive, unless specifically instructed to do so in the copy script. I'm positive that's not the issue...

Two things to check.

1. Go into Netinfo Manager. Navigate to the "users" entry, and then "maintenance". What does it say for the "home" entry under the maintenance user?

2. Try renaming the original volume before you reboot from the clone to something else ("original drive" or something). Does it still open files on that volume?

[macWish]

1. Netinfo manager: "/users/Maintenance"

2. If I rename the original source volume (i.e. the internal hard drive) and reboot from the clone, the startup process hangs on the Log In Window. If I select either of the two user options (Ronaldgold or Maintenance, the two user accounts), then I get an error dialog stating that that user cannot log in at this time.

In order to boot from the clone, I had to change name of source volume back to its original name. Then if I change the log in option to log in automatically to account Ronaldgold so that the log in screen does not appear, startup occurs uneventfully. However, if I check lsof, it still shows that the first login window file being accessed during startup is loginwn on MacIntosh HD, not on myClone.

It appears as if, for some unkown reason, during startup, the clone has to open the login window file on the source volume which leads to the subsequent problems with unmounting the source volume.

It also looks as if the clone opens a Finder file on the source volume related to Desktop.

loginwind 176 ronaldgold cwd VDIR 14,14 476 92106 /Volumes/MacIntosh HD/Users/ronaldgold
Finder 240 ronaldgold 11r VDIR 14,14 102 92117 /Volumes/MacIntosh HD/Users/ronaldgold/Desktop

[dnanian]

Well, you can see pretty clearly that Netinfo indicates that the home folder should be accessed from the root (/). That's what it should be (and what I expected).

At this point, I just don't know what's wrong. I've never seen this before and can't duplicate it... it's as maddening for me here as it must be for you there.

There must be something a bit unusual that's starting pretty early on your machine that's causing this to happen. Maybe it's a 3rd party something-or-other... so let's try one more thing.

Rename the original volume again to something else. Set the external to the boot drive, and shut all the way down. Hold down Shift and power on, keeping shift down until you see the "Safe Boot" indicator in the boot panel.

In "safe mode" can you log in?

[macWish]

After changing name of original volume, shutting down, and doing safe boot, I cannot log in. In order to log in, I have to have original name of the source volume even in safe boot.

After startup and logging in, I check Console. I don't know if the following has any significance in terms of the login issue, but the first line of the Console log is:

"Mac OS X Version 10.4.1 (Build 8B15)
2005-06-25 10:24:48 -0400
2005-06-25 10:24:51.161 loginwindow[107] FSResolveAliasWithMountFlags returned err = -43"

[dnanian]

OK. At this point, I'm really out of ideas, Ronald. Something very strange is going on here -- something I've never seen: for some reason, your system really wants to point to the internal drive. It's like there's a process attached to the login window that's forcing things to internal.

Could you send me a System Profiler report to the support email address? Maybe I'll see something in there that will help... make sure all the involved drives are attached.

[macWish]

Here, 3 months later, is response from Apple to my bug report:

Engineering has determined this issue behaves as intended based on the following information:

We replicated the issue using the 'Safety Clone' feature in SuperDuper. The Safety clone creates sym links back to the original volume, so there are open files. We were able to boot from the new volume and run disk util on the original.

Thank you for taking the time to submit this report.

Best Regards,

The Bug Reporting Team
Apple Developer Connection

No help at all at explaining the problem on my machine.

[dnanian]

Well, was it a Safety Clone? Perhaps they (or I) didn't understand...?

[macWish]

[QUOTE=macWish]Here, 3 months later, is response from Apple to my bug report:

Engineering has determined this issue behaves as intended based on the following information:

We replicated the issue using the 'Safety Clone' feature in SuperDuper. The Safety clone creates sym links back to the original volume, so there are open files. We were able to boot from the new volume and run disk util on the original.

Thank you for taking the time to submit this report.

Best Regards,

The Bug Reporting Team
Apple Developer Connection

------

I don’t understand this either. I interpret it to mean that they created Safety Clone, booted from it and ran Disk Utility while booted from Safety Clone and had no problem running Disk Util on the original. I do't understand how they can do this if there indeed are open files on the original when they boot from the Safety Clone.

My work around avoids the issue without explaining it: I installed Tiger on the partition on my external hard drive in addition to the Safety Clone. I use the Safety Clone as my startup volume and the Tiger Partition for maintenance.

[dnanian]

Certainly, if you're booting from a Safety Clone, you can't unmount the original volume -- after all, your Home folder is hosted there, since the user files are shared.

But -- if you're booting from a "regular" copy (as I thought you were -- that is, "Backup - all files"), there's no reason for the main volume to be busy as long as the backup is named the same...