I do wish I could reproduce this. I'd really suggest trying to stop all running processes that are user-based... there's clearly something weird being loaded from *somewhere* -- I just don't see how it's resolving to the wrong drive. Perhaps going the opposite way in your situation -- renaming the "original" drive to something other than "Macintosh HD" before booting from the clone -- would help to ensure things aren't doing something weird?

The cloning problem with Tiger is not unique to SuperDuper!. The exact same problem occurs when I clone with Disk Utility itself and with TechTool Pro (i.e. to create eDrive). The problem seems to be that, unlike Panther, when Tiger is cloned, a few files on the clone seemed to be linked back to the Internal Hard Drive. When I do safety boot of safety clone on external firewire drive into Maintenance User (which has no third party log in items) and then use "lsof" in terminal to list the open files, the following files which seem to be on Internal hard drive (MacIntosh HD) are open:

loginwind 156 maintenance cwd VDIR 14,2 476 117056
/Volumes/MacIntosh HD/Users/maintenance
Finder 188 maintenance 11r VDIR 14,2 136 117060
/Volumes/MacIntosh HD/Users/maintenance/Desktop
Finder 188 maintenance 13r VDIR 14,2 68 393078
/Volumes/MacIntosh HD/Users/maintenance/.Trash

All of the other open file listed by lsof are on safety clone.

If I boot into eDrive, then the only open file on internal hard drive is:

Finder 137 ronaldgold 11r VDIR 14,2 170 337370
/Volumes/MacIntosh HD/.Trashes/501

Apple Developer Bug reporter staff has not yet come up with an answer. Since I reported the bug one month ago, I am not to optimistic that they are dealing with it.

Well, that would make sense, though, if it's a Safety Clone, because a Safety Clone *does* link the users back to the original volume.

Yes but - this did not happen with OSX 10.3.9, but only with Tiger. And it also happens with Techtool Pro's eDrive (which is cloned by its own partition by TechTool Pro) and also when I make clone with Disk Utility and when I make complete clone with SuperDuper. Regardless of how I make the clone, with Tiger, but NOT with Panther, the cloning process creates some links back to the Source Volume for the Clone so that when I boot the clone, it opens the links. This makes it impossible to unmount the internal hard drive boot volume when unmounting is required by an application such as Disk Utility, Disk Warrior, or some parts of TechTool Pro. The only way I have found to get around this problem is to boot with the Disk Warrrior CD to check the Internal HD with Disk Warrior on the or with the Tiger Install DVD to check the Internal HD with Disk Utility. Given the very slow bootup times of CDs and DVDs, this is a pain.

Yeah, that I don't understand, but I definitely understand why a Safety Clone would have a link back to the main volume.

Complete clones, not so much. But -- if you name things properly -- this shouldn't happen. I'm at a loss, macWish.

I installed Tiger on a partition on my external hard drive. When I boot from that partition, Disk Utility has no difficulty in checking all of the other volumes on both internal and external hard drives. HOWEVER, when I cloned the Tiger partition with SuperDuper to another partition on the external drive, Disk Utility can unmount everything EXCEPT the Tiger partition which was the source of the clone. As before, lsof indicates that two files are opened on the Tiger Partition when I boot from the Tiger clone:

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

These are the same two culprits that caused the original problem. Clearly not an issue with Firewire drives. Why this happens with my setup with Tiger, but not Panther is beyond me. Others have not had this problem (see http://www.techsurvivors.net/forums/...=ST&f=1&t=9508)

The implication there is that the loginwindow process has that folder as the current working directory, and that you have it open as the desktop.

Have you messed with NetInfo at all?

No. I have never opened it. In Activity monitor, LoginWin is listed as being active with same process ID as listed by lsof. I don't have a clue as to why it is open on Internal Hard Drive. A bunch of my third party login items are also linked to Internal Hard Drive as would be expected on Safety Clone. Only LoginWin persists when I boot with no third party logins, along with Finder/desktop. Should I kill LoginWin via activity monitor as a test?

Is the volume capitalized/spelled *exactly* the same as the original volume? That could account for this kind of thing, too.

My internal hard drive is "McIntosh HD"; shared clone on external hd is "myClone".

Yeah, I see that I've suggested it previously in this thread, but I really think you should try to name the clone and the original *exactly* the same. Then, do the reboot and send me the same lsof output...

I renamed clone so that it matched internal hard drive exactly, and rebooted. No change in lsof output or in behaviour of Disk Utility. I have attached output to losf in a separate email to you.

Weird, Ronald. Going by the lsof logs, the volumes don't seem to be named the same:

Finder 95 maintenance 11r VDIR 14,2 136 117060 /Volumes/MacIntosh HD/Users/maintenance/Desktop
Finder 95 maintenance 12r VDIR 14,12 68 170117 /.Trashes/502
Finder 95 maintenance 13r VDIR 14,2 68 408673 /Volumes/MacIntosh HD/Users/maintenance/.Trash
Finder 95 maintenance 14r VDIR 14,13 68 107408 /Volumes/OSX Tiger/.Trashes/502
Finder 95 maintenance 15r VDIR 14,14 68 35797 /Volumes/Backup/.Trashes/502
Finder 95 maintenance 16r VDIR 14,15 68 247416 /Volumes/HD Clone/.Trashes/502

Did something go wrong in the rename? Or are the "clone" volumes other, unrelated backups?

The internal hard drive boot volume is "MacIntosh HD". On the external hard drive, my startup volume is a safety clone which I renamed "MacIntosh HD" by copying the name of the internal drive and pasting it in safety clone. I have three other partitions on the external firewire drive:
1. "Backup": a non-bootable partition to which I make nightly backups of my User files;
2. HD Clone: a complete copy clone of the internal hard drive which I do not use for startups;
3. OSX Tiger: a partition on which I installed Tiger directly from the Tiger DVD. If I boot from this partition, with OSX Tiger which is not a clone, there is no problem with Disk Utility.

Further mystification
 

Having learned on another forum that Carbon Copy Cloner can be used with Tiger by launching it via Pseudo in order to get root authentication, I used CCC to clone the partition on my external hard drive on which I had installed Tiger from the Tiger Install DVD (named "OSX Tiger". The clone creased with CCC booted without any problem and Disk Utility had no problem checking all of the bootable volumes on both the internal HD and external firewire hd. When I checked for open files with lsof, no files on OSX Tiger were open.

When I cloned this partition with SuperDuper! to a partition on the external fire wire drive and booted from the clone, I got the usual failure of Disk Utility and lsof indicated that the following files on "OSX Tiger" were open:

loginwind 143 maintenance cwd 3r VDIR 14,13 476 117056
/Volumes/MacIntosh HD/Users/maintenance
Finder 164 maintenance 11r VDIR 14,13 136 117060
/Volumes/MacIntosh HD/Users/maintenance/Desktop

Something changed with Tiger and SuperDuper! (and Disk Utility and TechTool Pro) so that it appears (to me) that a link to loginwin and Finder on the source volume are being created during the cloning process. This does not appear to occur with Carbon Copy Cloner (which is not officially Tiger-compatible but seems to work when launched via Pseudo).