Mac OS X Services in Snow Leopard
Mac OS X Services let one application supply its powers to another; for example, a Grab service helps TextEdit paste a screenshot into a document. Most users either don't know that Services exist, because they're in an obscure hierarchical menu (ApplicationName > Services), or they mostly don't use them because there are so many of them.
Snow Leopard makes it easier for the uninitiated to utilize this feature; only services appropriate to the current context appear. And in addition to the hierarchical menu, services are discoverable as custom contextual menu items - Control-click in a TextEdit document to access the Grab service, for instance.
In addition, the revamped Keyboard preference pane lets you manage services for the first time ever. You can enable and disable them, and even change their keyboard shortcuts.
Submitted by
Doug McLean
Recent TidBITS Talk Discussions
- Alternatives to MobileMe for syncing calendars between iPad/Mac (1 message)
- Free anti-virus for the Mac (20 messages)
- iTunes 10 syncing iPod Touch 4.1 (2 messages)
- Thoughts about Ping (16 messages)
Related Articles
- Mac OS X 10.6.3 Update Delivers Range of Fixes (29 Mar 10)
- How to Fix Snow Leopard's Finder-Copying Bug (19 Nov 09)
Published in TidBITS 1004.
Subscribe to our weekly email edition.
- Submit Ideas for the 2009 TidBITS Gift Guide
- Free Wi-Fi Abounds with Holiday Sponsorships
- New Ebooks about the iPhone and iPod touch
- HD Radio Comes to iPhone via Adapter
- DealBITS Discount: Save 30% on Labels & Addresses
- Fix 10.6.2's Broken Slide Show Screen Saver
- Catch a Google Wave with Waveboard
- WikiReader Puts Wikipedia in Your Pocket
- Put More Pixels on Your Desktop with ViBook+
- TidBITS Watchlist: Notable Software Updates for 16 November 2009
- ExtraBITS for 16 November 2009
- Hot Topics in TidBITS Talk for 16 November 2009
A Finder-Copying Bug in Snow Leopard
Here's a bug in Snow Leopard that I've isolated. I haven't seen it reported elsewhere (not in precisely this form, at least), so I'll describe it and let you reproduce it for yourself. You'll need two computers, one of them running Snow Leopard.
Preparation -- Let's call the machines A and B. Machine A must be running Snow Leopard. I don't much care what Machine B is running; I've tested with Machine B running either Leopard or Snow Leopard, and it makes no difference. Machine B must have File Sharing turned on. Once that's done, you will work entirely at Machine A.
Performance -- To see the bug, perform (on Machine A) the following steps:
- Mount Machine B on Machine A (via File Sharing). So, you're still working at Machine A, but in Machine A's Finder you can see Machine B's folders.
- Download The Omni Group's OmniDazzle, using this link. (The bug likely has nothing to do with Omni's applications per se, but many of them demonstrate the bug, so I've picked a small one that does.)
- If it hasn't automatically opened and mounted, open the downloaded .dmg file. Accept the legal agreement. You are now looking at the OmniDazzle application on the mounted OmniDazzle volume.
- Drag the OmniDazzle application from the mounted OmniDazzle volume to a folder of Machine B to copy it. You can't do it; the Finder puts up a dialog reporting Error -36. That's the bug.
Further Details -- The bug has nothing to do with the fact that the OmniDazzle application is initially on a mounted .dmg image. I just had you start with the mounted .dmg image for the sake of simplicity. If you copy OmniDazzle to Machine A (say, to the Desktop) and then try to copy that copy to Machine B, you'll still get the bug.
The bug is unidirectional. You can't copy OmniDazzle from Machine A to Machine B, but you can copy it from Machine B to Machine A (assuming you are working at Machine A).
The bug seems to affect only applications, but I'm not entirely sure about that. Moreover, it doesn't affect every application; as I said before, it affects most of Omni's applications, so I'm using one of them for demonstration purposes.
The bug has to do with File Sharing. If Machine A and Machine B are connected in some other way - for example, if Machine B is mounted in FireWire Target Mode on Machine A - there's no problem.
The bug has to do with Snow Leopard. If Machine A is running Leopard, there's no problem.
The bug has to do with the Finder. If you perform the copy using the Unix cp command in the Terminal, the copy succeeds. (A sample Terminal command is provided below; don't do this, though, unless you already understand cp, because the syntax here is tricky and there is some danger if you make a mistake.)
cp -a /Volumes/OmniDazzle/OmniDazzle.app /Volumes/mattleopard/Desktop/
When using cp in this way, some error messages do appear in the Terminal, but they don't seem to be fatal: the whole application is copied, and will run successfully on the remote machine. In fact, I wonder whether these error messages have something to do with the Finder's error message. Perhaps some reader who understands extended attributes and symbolic links better than I do can explain what's going on here.
address book, music, photos and much more between your phone
and Mac. Supports ANDROID, BLACKBERRY, PALM PRE and many
other phones. <http://www.markspace.com/bits>
http://www.readynas.com/?p=3137
When you copy the app in the finder, parts of the directory structure are copied, including a soft link, but not its target. My guess is that the finder does the same thing as cp -a, but checks for errors and gives up when it sees the errors that you see in Terminal.
If the targets were copied before the links, these problems should not occur.
When using cp's "-a" option, errors are ignored.
What gives you the right to transfer an app from one machine to another without authorization of the license from the creator of the app? If you have the EULA permission to transfer the software from one machine to the other, then maybe it will work, but the security feature is in place in Snow Leopard to keep you from making that faux paux.
I have my machine set up so I can't even move a file off my desktop to my hard drive without authentication first. It is a pain, but I accepted that level of security in order to protect my system.
Also, are you using FileVault by chance? (I'm not yet.)
This workflow is not an EULA violation in most situtionat. Machine A - downloads, opens DMG, installs to Machine B. It is never installed on Machine A so no EULA violation.
And this is a common workflow in a company where there is a central authority to install software and users must contact that authority to get new software (i.e. software license enforcement.)
This is not an intentional security feature (or it would happen with all apps, and with better explanations.)
Ditto command will work well for copying
apps also.