The macosxhints Forums - What's Wrong With This Shell Script?

The macosxhints Forums (http://hintsforums.macworld.com/index.php)

- UNIX - Newcomers (http://hintsforums.macworld.com/forumdisplay.php?f=15)

- - What's Wrong With This Shell Script? (http://hintsforums.macworld.com/showthread.php?t=113131)

I think any open file (or folder) will keep the volume from unmounting. Each of the lines you showed from 'lsof' indicates an open file ("REG") or folder ("DIR").
The first entry in each line is the program that has opened the file/folder.
I assume that "Path\x20F" is Path Finder.

You're right. It is PathFinder. But, I never have trouble manually unmounting the volume, even if PathFinder has it displayed in the sidebar under 'Devices'.

I may have overcome, if not solved the problem. I tried setting the 'sleep' time to 90 as follows:

Code:

(sleep 90; diskutil unmount "$2" >> /Library/Logs/CCC.log 2>&1; sleep 1; tail -n 25  /Library/Logs/CCC.log | mail -s "CCC" root) &

And, the volume was unmounted and the e-mail went out. I guess 60 was too short and 120 too long. I have no idea why. How could the extra 30 seconds cause the final command in the list to fail?

From the CCC.log fragment that was the body of the e-mail:

Code:

08/04 09:02:54        Blessing the target volume...

08/04 09:02:56        Running postflight script: /usr/share/Clone.sh

08/04 09:03:44        Updating the dynamic linker shared cache

08/04 09:03:44        Summary statistics: 

        Data copied: 2.52 GB [Please see http://www.bombich.com/software/docs/CCC/en.lproj/troubleshooting/log.html for a comment about this figure]

        Total data in file set: 190.45 GB

         Regular files copied: 1619

         Directories: 218922

         Regular files: 849285

         Symlinks: 20033

         Devices: 0

         Special files: 45

         Hard links: 34457

         Extended attributes: 729332 (9.63 KB)



08/04 09:03:44        The backup operation has completed. Elapsed time: 00:23:15

================================================================================





Volume Clorox on disk1s2 unmounted

08/04 09:05:17        [INFO] Volume unmounted: "/Volumes/Clorox"

I guess it will forever remain a mystery. Unless, of course, it fails again tomorrow…

What is update_dy?

Which it did. This morning the Volume failed to unmount. I did an lsof of the volume immediately after the sleep command:

Code:

(sleep 90; lsof | grep "$2" > /private/var/log/clorox.log; diskutil unmount "$2" >> /Library/Logs/CCC.log 2>&1; sleep 1; tail -n 25  /Library/Logs/CCC.log | mail -s "CCC" root) &

and it is absolutely full of stuff like this:

Code:

update_dy 79091           root  txt       REG       14,5    214672   628111 /Volumes/Clorox/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration

update_dy 79091           root  txt       REG       14,5     42464   626373 /Volumes/Clorox/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa

update_dy 79091           root  txt       REG       14,5    136976   626932 /Volumes/Clorox/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices

update_dy 79091           root  txt       REG       14,5   3686320  1126038 /Volumes/Clorox/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv

What is update_dy? I can't find a reference to it.

Code:

% man -k update_dy

update_dyld_shared_cache(1) - Updates dyld's shared cache

Thanks hayne. I tried both 'man' (without the switch) and 'which' on 'update_dy' and, of course, came up with nothing.

I'm assuming that this is running on the newly blessed clone and that the volume cannot unmount until this is done?