dmggraphicsmacos
Until MacOS 10.7, I used to put a png file in a read/write dmg, then I set it as its background picture, then I hided it and converted the dmg to a read-only one. Everything just worked.
Now, in MacOS 10.8, if I do the exact same thing, when I open the read-only dmg it opens the read/write one too. It looks like it "knows" the original background picture is on the read/write dmg. Even if the read-only one has the same image in its contents.
How can this be prevented?
Thank you for your input
So finally I managed to do it (at least I think so)
I embedded an Applescript to change the background in a shell script which I added it to launchd.
This is what it looks like:
Script "scriptly.sh"
#!/bin/bash
osascript -e '
set myhour to get the (hours of (current date))
set myminutes to get the (minutes of (current date))
set mypicturenumber to (myhour - 12) * 12 + myminutes / 5 as integer
if mypicturenumber < 0 then
set mypicturenumber to (288 + mypicturenumber)
end if
set picnumber to 0
if mypicturenumber > 99 then
set picnumber to "0" & mypicturenumber
end if
if (99 ≥ mypicturenumber) = (9 < mypicturenumber) then
set picnumber to "00" & mypicturenumber
end if
if 9 ≥ mypicturenumber then
set picnumber to "000" & mypicturenumber
end if
tell application "Finder"
set desktop picture to {"Macintosh HD:users:USERNAME:Individualfile:backgrounds:earth:earth24h" & picnumber & ".png"} as alias
end tell
'
launchd file "com.individual.Background.plist"
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.individual.Background</string>
<key>ProgramArguments</key>
<array>
<string>/bin/sh</string>
<string>/Users/USERNAME/Individualfile/scriptly.sh</string>
</array>
<key>StartInterval</key>
<integer>300</integer>
<key>UserName</key>
<string>USERNAME</string>
</dict>
</plist>
command to put it in action
launchctl load /Users/USERNAME/Individualfile/com.individual.Background.plist
EDIT:
The last command is there to load the script directly, however It will not be executed on startup. To do That you have to copy the file
com.individual.Background.plist
to the ~/Libary/LaunchAgents/ folder.
I've been interested in this question since Nov 2012 and even set up a FreeNAS VM to reproduce the issue.
I eventually gave up but since the question has been resuscitated I will share what I found out back then and in the last hours (luckily I didn't delete the VM) and what I think the cause for this issue is. I have also found a workaround.
First of all, this is my test setup:
OS X 10.8.2 (sorry, no 10.7.5 around).
FreeNAS (FreeBSD 8.2-RELEASE-p1)
(The OP's version is FreeBSD 8.2-RELEASE-p7 - I couldn't find the same version.)
A NAS filesystem in /mnt/raid:
A user named netboot:
An AFP filesystem (/mnt/raid/netboot) exported as netboot:
(Note that it is configured read-only).
An NFS filesystem (same path as AFP filesystem, to match the OP's configuration: /mnt/raid/netboot):
I mounted the AFP read-only filesystem as user netboot using the Finder with ⌘K:
and mounted a DMG image file without any problems:
$ sudo rm /private/var/netboot/Library-Shadow
$ sudo /usr/bin/hdiutil attach /Volumes/netboot/p7zip-9.04-0.i386.dmg -notremovable -shadow /private/var/netboot/Library-Shadow -owners on -noverify -noautofsck -nobrowse
Password:
/dev/disk3 Apple_partition_scheme
/dev/disk3s1 Apple_partition_map
/dev/disk3s2 Apple_HFS /Volumes/p7zip.pkg
Then I unmounted it and mounted the read-only NFS filesystem (I also used ⌘K) and couldn't mount the DMG image file.
I think the problem is logged here:
CBSDBackingStore::setPermission: opening /Volumes/netboot/Lion.nbi/Library.dmg
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000000 -> 0x00000014 (locks are MANDATORY)
CBSDBackingStore:OpenLockFriendly: could not open with lock 30
Error 30 means (see man 2 intro):
30 EROFS Read-only file system. An attempt was made to modify a file or directory was made on a file system that was read-only at the time.
No surprise here, it is indeed a read-only filesystem, but... when mounted over AFP it works, why?
Because Apple's NFS implementation has some problems with locking. As stated in this post at gluster.org:
OS X does a phenominal amount of file locking (some would say, needlessly so) and has always been really sensitive to the configuration of locking on the NFS servers. So much so that if you randomly pick an NFS server in a large enterprise, true success is pretty unlikely.
In my setup, the NFS server (that is, the FreeNAS VM) was suddenly irresponsive (from my Mac's /var/log/system.log):
Mar 15 15:35:04 avallone.local rpc.lockd[8119]: Lockd got unexpected signal 20
Mar 15 15:35:04 avallone com.apple.launchd[1] (com.apple.lockd[8119]): Exited with code: 1
Mar 15 15:35:04 avallone com.apple.launchd[1] (com.apple.lockd): Throttling respawn: Will start in 10 seconds
(...)
Mar 15 15:35:07 avallone com.apple.launchd[1] (com.apple.statd[8121]): Exited with code: 1
Mar 15 15:35:07 avallone com.apple.launchd[1] (com.apple.statd): Throttling respawn: Will start in 10 seconds
Mar 15 15:35:13 avallone kernel[0]: nfs server 172.16.54.186:/mnt/raid/netboot: lockd not responding
Mar 15 15:35:13 avallone.local KernelEventAgent[72]: tid 00000000 received event(s) VQ_NOTRESP (1)
Mar 15 15:35:13 avallone.local KernelEventAgent[72]: tid 00000000 type 'nfs', mounted on '/Volumes/netboot', from '172.16.54.186:/mnt/raid/netboot', not responding
(...)
Mar 15 15:35:34 avallone.local KernelEventAgent[72]: tid 00000000 unmounting 1 filesystems
The output of sudo /usr/bin/hdiutil attach -debug /Volumes/netboot/p7zip-9.04-0.i386.dmg -notremovable -shadow /private/var/netboot/Library-Shadow -owners on -noverify -noautofsck -nobrowse was:
CBSDBackingStore::setPermission: opening /Volumes/netboot/p7zip-9.04-0.i386.dmg
CBSDBackingStore::OpenLockFriendly: mapping flags 0x00000000 -> 0x00000014 (locks are MANDATORY)
CBSDBackingStore:OpenLockFriendly: could not open with lock 5
Error 5 means (again from man 2 intro):
5 EIO Input/output error. Some physical input or output error occurred. This error will not be reported until a subsequent operation on the same file descriptor and may be lost (over written) by any subsequent errors.
which isn't suprising at all, the NFS filesystem was gone.
A workaround (tested on OS X 10.8) is to mount NFS with options nolocks,locallocks. As explained in the post at gluster.org already mentioned:
Fortunately, there is a fix: just turn off network locking. You can do it by adding the "nolocks,locallocks" options in the advanced options field of the Disk Utility NFS mounting UI, but this is painful if you do a lot of them, and doesn't help at all with /net. You can edit /etc/auto_master to add these options to the /net entry, but it doesn't affect other mounts - however I do recommend deleting the hidefromfinder option in auto_master. If you want to fix every automount, edit /etc/autofs.conf and search for the line that starts with AUTOMOUNTD_MNTOPTS=. These options get applied on every mount. Add nolocks,locallocks and your world will be faster and happier after you reboot.
I manually mounted 172.16.54.186:/mnt/raid/netboot and it worked flawlessly:
$ sudo rm /private/var/netboot/Library-Shadow
$ sudo mount -o nolocks,locallocks,ro 172.16.54.186:/mnt/raid/netboot /tmp/mnt
$ sudo /usr/bin/hdiutil attach /tmp/mnt/p7zip-9.04-0.i386.dmg -notremovable -shadow /private/var/netboot/Library-Shadow -owners on -noverify -noautofsck -nobrowse
/dev/disk6 Apple_partition_scheme
/dev/disk6s1 Apple_partition_map
/dev/disk6s2 Apple_HFS /Volumes/p7zip.pkg
I also edited /etc/auto_master like this:
+auto_master # Use directory service
#/net -hosts -nobrowse,hidefromfinder,nosuid
/net -hosts -nosuid,nolocks,locallocks
/home auto_home -nobrowse,hidefromfinder
/Network/Servers -fstab
/- -static
stopped and started automountd and autofsd:
$ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.automountd.plist
$ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.autofsd.plist
$ sudo launchctl load /System/Library/LaunchDaemons/com.apple.autofsd.plist
$ sudo launchctl load /System/Library/LaunchDaemons/com.apple.automountd.plist
and worked like a charm:
$ cd /net/172.16.54.186/mnt/raid/netboot
$ ls
Network Trash Folder Temporary Items p7zip-9.04-0.i386.dmg
$ sudo rm /private/var/netboot/Library-Shadow
$ sudo /usr/bin/hdiutil attach p7zip-9.04-0.i386.dmg -notremovable -shadow /private/var/netboot/Library-Shadow -owners on -noverify -noautofsck -nobrowse
/dev/disk7 Apple_partition_scheme
/dev/disk7s1 Apple_partition_map
/dev/disk7s2 Apple_HFS /Volumes/p7zip.pkg
Best Answer
You're right. The original disk image is opened when opening a newly converted read-only image. However, I found that if you delete the original read-write disk image, Finder (actually, DiskImageMounter) has no problem mounting the read-only image without its original. DiskImageMounter itself is not really responsible for the behavior you are talking about; if you look at your read-only image's .DS_Store file in TextEdit, you'll see (amidst very obscure symbols) your original image's name and file path in many places. This is just built-in behavior of Mountain Lion, I suppose. Unfortunately, there are no workarounds except for deleting the original image (and emptying the Trash) because Disk Utility is ultimately responsible for the creation of the DS_Store file, and the image created is read-only.