Sandbox failing oddly

[camner]

A short while ago I needed to change the size of my Sandbox, which is a partition on the same drive as my main volume ("Macintosh HD"). To do this, I cloned Macintosh HD to an external drive, and then used Disk Utility to repartition the drive. Obviously, this erased the volumes. I then recloned back to Macintosh HD from the external drive and recreated the Sandbox and booted off the Sandbox.

So far so good. A couple of days later, I rebooted my machine (from the Sandbox) and it was as if it booted with a different user (though it didn't--the user was the same, as I only have 1 user set up). All of the user preferences were no longer being respected. I got a "fresh" desktop, and the icons for Documents and Downloads were question marks.

I then recreated the Sandbox using "shared users and applications" and "smart copy" and all seemed to be well.

A couple of days later, I rebooted again from the Sandbox, and same problem. In the meantime I had rebooted at least a couple of times off of Sandbox without an issue.

Something seems to be failing here...any thoughts about what it might be? Some kind of corruption issue, it seems.

[dnanian]

That seems weird. The only thing I can think of is that the 'original drive' was, for some reason, either not present or had a different name...

[camner]

Originally Posted by dnanian

That seems weird. The only thing I can think of is that the 'original drive' was, for some reason, either not present or had a different name...

No renaming as far as I can determine (at least I didn't do anything to rename). What I noticed was that once the Sandbox wouldn't correctly boot (well, that's not quite accurate...it booted, just didn't find the appropriate user settings) rebooting again had no effect. I had to recreate the Sandbox again.

Is there a possibility that something is amiss on the "underlying drive" such that the symlinks created by SD! are getting corrupted? I did run both Disk Warrior and the disk repair facility in Disk Utility. The former showed some little stuff (such as incorrect icons), and Disk Utility showed nothing wrong.

[dnanian]

Sure, that's possible... but not likely. I really don't know why that would be unless, again, the drive wasn't available for some reason when you logged in. Very strange.

[camner]

Originally Posted by dnanian

Sure, that's possible... but not likely. I really don't know why that would be unless, again, the drive wasn't available for some reason when you logged in. Very strange.

Strange indeed. I'll keep an eye out. Correlation doesn't imply causation, of course, so it may only be coincidence that the problem occurred after I repartitioned my drive (which required a "clone/reclone back").

(I want to state explicitly what I hope is implicit is that I am emphatically NOT suggesting that SuperDuper is in any way responsible for this behavior. I don't have ANY reason to suggest this is the case.)

[dnanian]

Oh, I understand. I don't think it's SD! either. After all, a Sandbox is just a copy with symlinks, and when you're running from it we're not doing anything at all.

What's unexpected is that something would change that would 'break' the connection between the volumes.

[camner]

OK, it happened again. Look at the screenshot. When the Sandbox rebooted, the user <robertcamner> on Sandbox was no longer a symlink.

Now, what I've been doing is trying to fix a problem with Time Machine, and I've been deleting the .inprogress file made by TM, but I can't see how that could recreate the user folder.

[dnanian]

Me neither. Something clearly deleted it, though.

[camner]

OK, I may be onto something. I'm pretty sure I can reproduce the issue I'm having, which is always a good start...

This all began when Time Machine was failing because I repartitioned my hard drive. What I've learned from Googling is that when one repartitions a drive the UUID of the partitions (even if named exactly the same as before) will change, and TM doesn't like that. If I understand correctly, that's because when TM goes to back up a volume with the same name as the volume that has been backed up before to the TM drive, if the UUIDs of those identically named volumes are different, TM fails with this error message: Unable to complete backup. An error occurred while linking files on the backup volume. TM seems to have no problem if the volume name changes...

I've been trying to fix my TM without erasing my Time Machine drive and starting over again. This has led to repeated TM backup failures (my experiments have not been bearing fruit, alas...).

Now, here's where things get interesting as far as SD! is concerned. I've been booted from my Sandbox when doing this. Whenever a TM backup fails with this error message, upon the next reboot, the user directory symlink on the Sandbox has been hosed (see screenshot in my previous post).

I suppose if I want to explore this further I could try to make a "failed" TM backup while booted from my main drive "Macintosh HD" and see what, if anything, happens to the user folder. I'm not sure I'm going to do this, but if I do, I'll be sure to make a complete clone first!

Admittedly this is a low-probability event....

[camner]

Well, it's not quite that simple. This is proving difficult to track down, and it is very frustrating, because rebooting from the Sandbox will periodically fail with the symlink to the main volume user folder broken.

I have a question about how the Sandbox works (or really, it's how Mac OS X works). My Sandbox and main volume are on the same physical drive. I'm trying to figure out when the symlink breaks.

If the symlink breaks while I'm booted off of the Sandbox, would I notice it immediately, or only if I attempted to access my userfolder via the symlink?

Is it possible that the symlink is breaking during the boot process? What happens if doing boot time the Mac tries to follow the symlink and for some reason cannot? Will it automatically create a new user folder?

[dnanian]

Your User Folder is being constantly accessed when you're logged in, so you'd likely notice it right away.

If they're both on the same drive, then the original drive would certainly be available at login time, which kills my theory.

Are you using any programs that you haven't used before? Perhaps one is messing with the symlink?

[camner]

The only thing I've been for a bit which is unusual (and which clearly involves symlinks) is to use both Time Machine (to delete some items) and software called "Back-in-Time" which allows for individual instance deletions from Time Machine. Back-in-Time also "messes with symlinks" because it has to destroy some symlinks on the TM volume and recreate others. Other than that I don't know how it does its magic.

[dnanian]

Well... perhaps you need to try not using either to see if that has any effect?

[camner]

Yup! That's exactly what I'm doing now.

One clear oddity (or maybe merely "another clear oddity"...)...

I deleted something using Time Machine (booted into the Sandbox)
I looked at the Sandbox and found the user folder symlink and it resolved perfectly
I rebooted into the Sandbox
....no symlink of the user folder! How could it break in the shut down/reboot process when nothing else had happened since I checked it?

A question...how can I tell the difference between a symlink and a normal alias? When I said "symlink was fine" all I REALLY know that a file with an icon with a little arrow on it resolved correctly. Could something have replaced a symlink with a normal alias which doesn't resolve correctly on boot up?

Just casting about here....

[dnanian]

No, I don't think anything would do that. (You can check a symlink vs. alias in Terminal with "ls -l"...