View Single Post
  #1  
Old 04-01-2007, 07:40 PM
Nunibad Nunibad is offline
Registered User
 
Join Date: Mar 2007
Posts: 2
"Did not copy tftpboot..." oddity.

In a recent smart-update I noticed this message in the log:

| 02:31:38 PM | Info | Did not COPY shared-item /Volumes/Macintosh HD/private/tftpboot/private/tftpboot because it would have overwritten the original

Everything seems fine; but I'm ("proactively") posting this because I don't understand why this should have happened. Details follow (and full log is attached).

1. Volume Macintosh HD (10.4.8) backed up (all files, "dumb") to A60 (external firewire).
2. MHD sandboxed to X (external firewire).
3. X combo upgraded to 10.4.9, and used for some time (pointing to MHD).
4. While booted from X (now 10.4.9) backed up MHD again to A60 (all files, smart this time).
5. Found the log entry above.

The reason this seems strange (to me) is that I did not expect to find "sharing" behaviour when copying from a volume (MHD) -to- which I'd never sandboxed. (I had only sandboxed -from- it.) Why did the backup not find the two copies of the link tftpboot identical, and simply skip it?

Another point is that the link tftpboot seems to be an "absolute" symlink, and it points to "/". Does that mean it's pointing to the root of volume X during this procedure (since I was booted from there)?

I'm unable to reason this out completely (by myself) as I'm not sure just exactly how smart update decides between overwriting, skipping or "not copying". Maybe they were considered different because during the original copy "/" was MHD but during the second copy "/" was X?

But (as I say) there seem to be no problems, so in a sense there might be nothing to fix. Nevertheless the process of smart-updating MHD to A60 while booted from X which itself is a sandbox of MHD... might be unusual enough that a potential gremlin is there.
Attached Files
File Type: zip 2007-04-01 13-47-33 +1000.txt.zip (4.9 KB, 1068 views)
Reply With Quote