Aaron Hall noted+on+the+MacEnterprise+list that the font caches in Leopard “seem to be under /var/folders now, but you can manipulate them with the cool new atsutil in Leopard.”
The atsutil command is quite an interesting find to me, so I wanted to point it out.
Microsoft released Service Pack 1 to update Office 2008 for Macintosh on Tuesday, May 13. The update makes a significant number of changes — spread across Entourage, Word, Excel, and PowerPoint — so if you are a system administrator, I would recommend examining the full description of Office 2008 for Mac Service Pack 1 (12.1.0) in its release notes.
The update is downloadable via Microsoft AutoUpdate (invoke that helper program with Help > Check for Updates in any of the Office applications, or look inside /Library/Application Support/Microsoft in the file system) as well as the Microsoft Office for Mac Web site.
It took me a little while to figure out how I could tell what DirectoryService directory nodes are available to a Mac OS X system. I could perform the task interactively, just issuing an “ls” command at the
dscl “>” prompt. But for a non-interactive one-liner, I was bedeviled by what I thought was a pretty basic function for the
I wanted to find all of the top-level nodes — because, for example, that could tell+me+if+I+really+had+access+to+an+Active+Directory+or+not.
It turns out that I was missing the use of “localhost” as the datastore parameter, which reliably returns the information I wanted in a parsable form. Rather than “/” (simply doesn’t work) or just a period (only uses the local directory) — or even listing "/Active\ Directory" explicitly — “localhost” specifies all of the directories available to the local host. I was incorrectly assuming “localhost” would tie me to the local directory, as with “localonly,” and I thus avoided trying it until I felt like an utter failure.
$ dscl localhost -list .
This produces the following output on a Leopard-based system which only has local accounts in DSLocal:
$ dscl localhost -list .
If your system happens to be bound to a Microsoft Active Directory, you’ll instead see it prepended:
$ dscl localhost -list .
Or if you’re on Tiger — again bound to Active Directory — you’ll still see “Bonjour,” “NetInfo,” and “SLP” in the mix:
$ dscl localhost -list .
I had a good example today of how mismatched UIDs between Exchange meeting updates and existing events can affect Microsoft Entourage’s processing of those incoming updates.
I used the same drag-and-drop-to-export methodology as in my previous article. The iCalendar .ics file for the existing event that I dropped out of my Entourage calendar contained these unique identifiers:
The e-mail cancellation from the meeting organizer, when dropped into the Finder as a .eml file, had the following unique identifiers:
As we can see, even though these were supposedly for the same event, neither the UID nor the X-ENTOURAGE_UUID properties matched. I emphasize the UID property because, as per my post on matching UIDs between Exchange meeting updates and existing events in Microsoft Entourage, I believe it to be the most important.
Both I and the meeting organizer are Entourage users in this case. That may be why both the event and the cancellation had X-ENTOURAGE_UUID properties at all. The UID property has appeared consistently for me in both events and their updates, no matter what their source.
Because of the discrepancy between unique identifiers, Entourage apparently couldn’t determine whether the cancellation was for the event that existed in my calendar. When Entourage “processed” the cancellation, it removed nothing from my calendar.
This seems entirely reasonable, although I would personally like Entourage to do deeper matching if it could: how about “is there an existing event by the same organizer and/or with the same name at the time of the update or cancellation?” Matching UIDs has got to be simpler.
How does this happen? Well, for me, it could have happened any number of ways: There could have been a past error when:
As far as I can determine, when you have data synchronization problems, you’re going to have one of the following outcomes:
Not all of these are pleasant, mind you — and that can depend on the circumstances involved. Deleting data is perfectly acceptable in some scenarios where it needed to be removed, but not others where it means it has just been lost. Adding data is great, unless it results in unwanted duplicates.
Anyway, I hope this helps you understand how Microsoft Entourage works a bit better.
Now that I have my dual-monitor Gateway FPD2485W setup, I’ve got a few complaints. Of course!
The two monitors take an awfully long time to wake up from their power-saving mode. Then, when they finally wake up — invariably at different times, the newer one first — I get the on-screen display (OSD) overlay telling me that they’ve chosen to accept the DVI input.
Well, duh, that’s the only video source hooked up to them, so it’s not helpful. This wouldn’t be so bad, but the OSD overlay stays on the screen for what seems like eons. Since the overlays are smack dab in the middle of the screen and are opaque, they block important visual elements like Mac OS X’s login window.
So far, I haven’t been able to find out how to get rid of the OSD overlay. If I could do that, I think I’d tolerate the wake up delay more readily.
Certainly, some of this is Gateway’s fault. I guess I can’t blame them much since they specifically don’t support Macs and that’s what I’ve hooked the flat panels up to. I could have gone with some brand that did advertise Mac support, but I didn’t. This must be my payback. Grin.
I’ve found that trying to explain the Mac OS X keychain at all tends to make peoples’ eyes glaze over. The keychain is poorly-understood overall, perhaps because it tries to bridge the gap between security and convenience.
A few thoughts:
When Microsoft Entourage is handling meeting updates or cancellations between Exchange users, it’s critically important that it can match up the change to an event with the correct event in a calendar. It does so by comparing unique identifiers between the update/cancellation message and existing calendar events. As nearly as I can tell, this depends on having the right UID, which makes sense.
How can you see the UID for events? Drag the event from an Entourage calendar to a Finder window, where it will become an vCalendar/iCalendar-formatted file with a .ics extension. You can open the resulting file in a text editor. Here’s a sample from a repeating event in an Entourage calendar, with the UID highlighted:
PRODID:-//Microsoft Corporation//Entourage Mac 11.0 MIMEDIR//EN
TZID:GMT -0500 (Standard) / GMT -0400 (Daylight)
DTSTART;TZID="GMT -0500 (Standard) / GMT -0400 (Daylight)":20080305T100000
DTEND;TZID="GMT -0500 (Standard) / GMT -0400 (Daylight)":20080305T113000
Similarly, you can drag and drop a proposed change to an event, which is received by e-mail (because Exchange is largely an e-mail based — rather than a network-based — calendar system), to the Finder. This will save the message as the text source of the e-mail, with a .eml extension. That file can also be opened in a text editor, where you can see that it contains a siginficant amount of vCalendar/iCalendar data. Here’s a sample cancellation notice that removes one instance of the recurring event from Entourage — for reference, not the instance shown above, but another one from the same sequence:
PRODID:Microsoft CDO for Microsoft Exchange
TZID:GMT -0500 (Standard) / GMT -0400 (Daylight)
DTSTART;TZID="GMT -0500 (Standard) / GMT -0400 (Daylight)":20080423T100000
Note that the UID properties match.
If you are troubleshooting a problem where an update/cancellation does not modify an existing event as you expected, and the UIDs of each do not match, that’s probably the source of your problem. Of course, you still have to figure out why the UIDs don’t match. In that case, I’d personally start by looking at what other synchronization software (besides Entourage’s own Exchange sync) and devices are involved.
Here is a table that combines each unique package whose Bill of Materials (BOM) file is checked by Disk Utility when running the Repair Permissions routine. These package names are directly listed in the DiskManagementTool (Panther, Tiger, and Leopard) or DiskFirstAid (Jaguar) executables.
For context, please see the previous post, Will the real Repair Permissions please stand up?
I would say that “many Bothans died for this,” but that would be overly sensational. I’m not sure anyone really cares besides me, so its importance in the galactic scheme of things is in doubt. Beyond that, it just took some time to generate each of the OS installs via InstaDMG; with the resulting disk images mounted, I just had to read files with the
strings utility. I didn’t even need to boot them. (Although, had I wanted to boot them, realize that Mac system administrators, like their developer friends, vote for virtualization.)
How did I construct this table? I got the raw data from the techniques described in the previous post. I saved the results into one text file for each OS version.
I ran the following command to get the the unique package names from my four text files:
$ cat 10200.txt 10390.txt 10411.txt 10500.txt | sed s/^\/Library\/Receipts\/// | sed s/\/Contents\/Archive.bom\$// | sort -f | uniq
sed commands strip the beginning and end of each line, which contain the beginning and ending of the full package and BOM path. This is the same for each package, and thus becomes superfluous in the table. The
sort command sorts the results, ignoring case (-f). Then,
uniq can determine which of the packages names are unique from the sorted data.
I pasted the output into Excel as a column. I then ran another set of commands to
grep for the package names in the original files, reviewed that output, and put an “x” in the right columns to denote which OS versions had which packages listed. Sorry, I didn’t write a script for that and the commands to get there were just:
$ for pkg_file in
cat uniq.txt; do grep "$pkg_file" *.txt ; done | pbcopy
The output from Excel was then used to make the table.
There has long been confusion and misunderstanding about what, exactly, the Repair Permissions routine in Apple’s Disk Utility does. What started as the Repair Privileges Utility available separately for Mac OS X 10.1 has become the subject of some controversy in the intervening years.
“What permissions does it verify?” and “Where does it get the list of permissions it uses for comparison?” are two reasonable questions users and system administrators alike may ask in order to understand the software better.
The answers to these questions are important to prevent the abuse of this technique in the no man’s land of troubleshooting voodoo. Repair Permissions has been debated ad nauseum, but confusion blankets it like a thick fog. It’s 2008 and yet I still come across reasonable people who don’t know what the software is doing — sometimes even holding that it is doing something it isn’t.
Well, there is information available on this topic. First, let’s look at Apple+Knowledgebase+Article+25751:+About+Disk+Utility’s+Repair+Disk+Permissions+feature. As of this writing, it states:
“When you use Disk Utility to verify or repair disk permissions, it reviews each of the .bom files in /Library/Receipts/ and compares its list to the actual permissions on each file listed. If the permissions differ, Disk Utility reports the difference (and corrects them if you use the Repair feature).”
That seems to imply that all of the Bills of Material (BOM) files for every package listed in /Library/Receipts are reviewed. But, the article further explains:
“No [Disk Utility does not check permissions on all files]. Files that aren’t installed as part of an Apple-originated installer package are not listed in a receipt and therefore are not checked. For example, if you install an application using a non-Apple installer application, or by copying it from a disk image, network volume, or other disk instead of installing it via Installer, a receipt file isn’t created. This is expected. Some applications are designed to be installed in one of those ways.”
The article implies that every package receipt is reviewed, but only the files and directories listed in an Apple-originated package are checked and repaired by Repair Permissions. This is somewhat confusing, since it doesn’t really explain how third-party software installed through an Apple installer package relates to this — particularly in the case where a file or directory is in both an Apple-originated package as well as a third-party one.
Macworld magazine’s Dan Frakes tackles the situation with the article Repairing permissions: What you need to know. The author tracks what BOMs Disk Utility is using while running Repair Permissions via
fs_usage. He also runs
strings on the tool that repairs permissions to find what, if any, BOMs are listed in the executable. Based on that evidence, he finds that a limited subset of BOMs are consulted by Repair Permissions — and all of them are Apple-originated; none are from a third party.
This dovetails nicely with the discussion of Repair Permissions in Michael Bartosh’s excellent Essential Mac OS X Panther Server Administration book from O’Reilly. While Mike is no longer around to explain how he obtained the list of BOMs — printed on page 163 — that are referenced by Disk Utility, it is likely he used one or both of the methods above. It is also likely he had access to information from Apple itself before he made the assertion. He always seemed to prize strong evidence and a deep understanding of the software, and so I trust what he wrote.
Mac OS X Leopard’s online help probably has the best clarification of the matter from an official source. It is succinct and much better than the Apple KB article when it spells out:
“Disk Utility repairs the permissions for files installed by the Mac OS X Installer, Software Update, or an Apple software installer. It doesn’t repair permissions for your documents, your home folder, and third-party applications.
You can verify or repair permissions only on a volume with Mac OS X installed.
It’s best to start up your computer using a disk with the latest version of Mac OS X, including software updates. Software updates may change file permissions to improve security.”
I think we can consider this matter settled; Disk Utility’s Repair Permissions routine is limited in scope. It only uses BOM files from Apple installer packages, and the only packages examined by the utility are those from Apple. Third-party software, even when installed by an Apple package, is not in the mix. The repair process only needs to be run as a troubleshooting technique when you think there is a problem related to the permissions-on-disk.
If you want to do your own sleuthing, the MacWorld article shows how to run
strings against the DiskManagementTool executable to find which BOMs it lists. Modifying that a bit to get the information from any given disk you’ve mounted, and placing the output on the pasteboard (so you can paste it in the editor of your choice), you get the following (substituting the volume’s path for “/path/to/startupvolume,” or just take that text out to use your current startup disk):
$ strings /path/to/startupvolume/System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/Resources/DiskManagementTool | grep Receipts | pbcopy
Neither the DiskManagement framework nor the DiskManagementTool exists in Jaguar, however. I found that the on-disk structure of Disk Utility changed between Jaguar and Panther. After discovering that change, I thought I’d need to substitute “Disk Utility.app/Contents/Resources/Disk Utility Agent” for DiskManagementTool, but even that executable didn’t contain any references to “Receipts.” Instead, I settled upon the following for Jaguar:
$ strings /path/to/jaguarvolume/Applications/Utilities/Disk\ Utility.app/Contents/Resources/DiskFirstAid.bundle/Contents/MacOS/DiskFirstAid | grep Receipts
The result is much shorter: only 12 BOMs are referenced in Jaguar, in contrast to 47 in Leopard. For more, see Packages consulted by Repair Permissions in Jaguar, Panther, Tiger, and Leopard.
Both Safari and Terminal gained drag and drop repositioning of tabs in Leopard. (True, Safari 3 also installs on Tiger as well as Microsoft Windows, but I've only used the new tab features under Leopard.) Since there has been discussion of the gestures required to reorder tabs within a window vs. drag them into new windows entirely, I wondered if the same was true for Terminal. (See Safari’s tab dragging modes and Safari 3.0: Dragging tabs up or down to move them sideways for more.)
Sure enough, I see the same results:
So, perhaps there is some grand design at work here, and this odd user interface is actually intentional. (It’ll probably get tied to some multi-touch trackpad action soon, right?)