Mac OS X 10.4 (Tiger) #14: More on managing Widgets; Another CD/DVD burning fix; iSync problem; Classic startup; DHCP; more

CNET staff

Sept. 2, 2009 11:24 a.m. PT

9 min read

Another method for monitoring your Widgets folder Yesterday, in our coverage of an emerging issue where malicious, or at least annoying Widgets could be installed, without the user's knowledge to be activated the next time Dashboard is accessed.

We noted a number of methods for sealing off this potential vulnerability, including the usage of a folder monitor utility like Folder Spy to enable alerts when changes are made to the ~/Library/Widgets folder (where any user-installed Widgets are normally stored).

You can also monitor any additions to this folder (introduction of new Widgets) through the use of Mac OS X's built-in Folder Actions via the following process:

Control-click (accessing the contextual menu) anywhere in a Mac OS X Finder window or on any folder and select "Enable Folder Actions."
Navigate to the ~/Library folder and select the "Widgets" folder.
Control-click on the "Widgets" folder and select "Attach a folder action."
Select the script "add - new item alert.scpt" (located in the folder /Library/Scripts/Folder Action Scripts/ which should appear immediately by default) and press the "Choose..." button.

You will now be presented with an alert whenever a new Widget is added to the ~/Library/Widgets folder. If this happens when visiting a new Web page, do not access Dashboard again until verifying the Widgets trustworthiness, and removing it (if necessary) from the ~/Library/Widgets folder manually or using a utility like Widget Manager.

AirPort/WiFi connections dropping when switching access points, solutions Several readers have noted that, under Mac OS X 10.4 (Tiger), the wireless AirPort connection drops when a system is moved from the range of one access point into the range of another access point -- even if the second access point is set up to be a wireless repeater, or vice versa.

Apple acknowledges this issue in Knowledge Base document #301322, and says users in this situation should renew their IP address to restore access via on of the following methods:

Put the Mac to sleep then wake it back up
In the "Network" pane of System Preferences, choose AirPort from the "Show" menu, click the TCP/IP tab, then click the Renew DHCP Lease button.

More on CD/DVD problem: Resetting PRAM/NVRAM Yesterday we continued coverage of an issue where Mac OS X 10.4 (Tiger) generates the error message "The disc cannot be used because the disc drive is not supported. (Error Code 0x80020025)" when a blank disc is inserted into a CD or DVD recorder and accessed via the Finder.

Our previously reported solution was inserting the CD, allowing the error message to pop up, then force quitting the Finder (either via the Apple menu "Force Quit" option, or by holding down the "option" and "control" keys in tandem, clicking on the Finder icon in the Dock and selecting "Relaunch").

Now, some readers experiencing this problem have noted that resetting PRAM and NVRAM via the following process (as described in Apple Knowledge Base article #2238):

Shut down the computer.
Locate the following keys on the keyboard: Command, Option, P, and R. You will need to hold these keys down simultaneously in step 4.
Turn on the computer.
Press and hold the Command-Option-P-R keys. You must press this key combination before the gray screen appears.
Hold the keys down until the computer restarts and you hear the startup sound for the second time.
Release the keys.

iSync 2.0: Problems synchronizing phones, iPods -- caused by "bad" Address Book contacts Several readers have reported an issue where iSync 2.0 launches when their Bluetooth or USB-enabled phone, or iPod is connected and seems to appropriately synchronize data at first, but either completes without any information actually being sent to the phone or iPod or stalls with an error message.

In some cases, this issue can be caused by a "bad" contact in Address Book. In this case, the workaround is a tedious process that requires testing batches of contacts at a time.

A poster to Apple's Discussion Boards, Drew Pauley, describes the process he used:

First, back up your Address Book (File > Back up Address Book...)
Now select all of your contacts A through M and hit delete.
Open (or switch over to its window if already open) iSync, and see if your groups show up in the list. If so, you know that the bad card is in the first half of the alphabet. If not, hit undo in Address Book and try deleting N through Z instead. If your groups now appear in iSync, your bad card is in the last half of the alphabet.
Hit undo to get all of your contacts back.
Add a group in Address Book to use as a flag for testing. (If the bad card is in Address Book, the group list in iSync won't refresh when you switch to iSync, but if all is well, the list will refresh.)
Now go through your contacts a chunk at a time, deleting, checking if the group list in iSync refreshes, and then undoing in Address Book. When the list refreshes, you'll have further narrowed down which is your bad card. Add another group to Address Book at each stage (or remove the previous one), to continue to have an indication of when the list is refreshing or not.
Continue this process until you know exactly which card(s) are the bad ones and remove them permanently.
Finally, you can re-enter the bad contact(s) by hand.

Shortening the computer name for DHCP issues, more We previously reported that shortening the Computer Name (to less than 6 characters) in the Sharing pane of System Preferences can resolve issues with D-Link routers, as well as with AirPort access.

We've now received word from a number of readers that the same process in fact resolves an underlying DHCP issue that affects D-Link routers and some AirPort configurations.

MacFixIt reader Al Spiegleman writes:

"Wrote earlier about a DHCP issue with Tiger - Seemed to affect some machines and not others. After talking to Apple tech support at length the only thing that they could offer is to change the computers share name. I was a little skeptical at the time, but I actually did it on a desktop and a couple of powerbooks, and lo and behold - they started getting DHCP addresses again.

"The actual fix involves going into the sharing preference pane and changing the computers name to a single word (I have kept it less than 6 characters, but I have no idea what the limit is) and closing the pref pane. DHCP will start to work immediately - either hard-wire or wireless. Don't even have to reboot.

"Trying to analyze what has changed - it appears that Tiger issues the DHCP request with a host name, which Panther did not. Appears that most implementations of DHCP have a limit on the number of characters (or words - not sure which) in the host name. The real problem of course, is with computers that have been set up with a long computer name because when you set up your Mac, the default is simply your name as typed in your log on, with "'s computer" added at the end. My partner's powerbook share name was 'Bruce LeVasseur's Computer". Changed it to blpbg4, and it magically started working again. My powerbook's name was G3400, so of course it worked fine without a change. This was a really tough one to diagnose, as it affected some machines consistently, and some not at all.

"Not sure if this is an Apple problem, or a DHCP problem, or a DHCP implementation problem, but this seems to fix the issue across the board - WAPs - DSL modems - Routers - you name it. Solved at least 12 customers' problems today with this."

Problems starting Classic -- possible fix A number of readers have reported problems starting Classic under Mac OS X 10.4, as previously documented.

MacFixIt reader Adam North, for instance, writes:

"I had a Classic installation that was fine under 10.3.x Upgraded to Tiger tonight and classic will not startup. I get the updating system components message after which I get the OS 9.2 splash screen and then a big stall. No extensions appear to load along the bottom of screen. Tried all the recommended tricks: fixed OS 9 permissions, fixed permissions on boot drive, tried to boot classic with extensions off via system preferences, tried to boot classic by calling extensions manager, reinstalled classic startup.app with pacifist off of Tiger DVD"

Some users experiencing this issue may be subject to a conflict caused by the QuickTIme DiVX 5.2 component.

This file is located in the /Library/QuickTime folder. If you are having problems starting Classic, try removing the DiVX component from this folder, and attempt to re-launch Classic.

Zip drive recognition problems Some users report that Iomega Zip drives built-in at the factory on older Mac models are no longer recognized under Mac OS X 10.4 (Tiger).

MacFixIt reader Randy Rogers writes:

"I ordered my Dual G-4 500 AGP with a built-in Zip 100 Drive, and it no longer works with Tiger. It worked fine up until I installed Mac OS X 10.4.

"I also reinstalled the Previous Drivers from Iomega, but that did not help either. I then went to Iomega's website, and they say that 10.4 is not supported. I hope that they put out some drivers soon.

"I can't eject the disk since it does not mount on the desktop, and Disk Utility as well as TechTool Pro 4.04 does not show it as a disk that is in the drive."

Iomega SCSI drives are known to cause some serious issues with Mac OS X 10.4 (Tiger) systems in some user configurations (see the SCSI section below for further details)

Note, however, that Iomega REV FireWire drives are compatible with Mac OS X 10.4 (Tiger) with the use of updated drivers.

Confirmation for Adaptec SCSI fix We've received several notes of confirmation from readers who have successfully applied the workaround mentioned earlier this week which involves removing several kernel extensions to allow proper operation of some Adaptec SCSI cards under Mac OS X 10.4.

To recap, the workaround involves removing the following files from the /System/Library/Extensions folder:

Adaptec 290X-2930.kext
Adaptec 29160x.kext
Adaptec 39160x.kext
Adaptec 78XXSCSI.kext

but leaving the file

Adaptec 78XXSCSI.kext

in place, then restarting.

MacFixIt reader Steve Morris writes:

"I left Adaptec78XXSCSI.kext as the only SCSI Adaptec driver (had the newest date) and that restored my 2906 card and scanner. Also now when I look in system profiler, I see one UMAX Scanner in the Parallel SCSI device tree not multiples I had seen before."

Despite success of the above workaround, various SCSI devices are still causing major problems with Mac OS X 10.4 including problems installing the OS, starting up, shutting down, or using other devices. If you are having such problems, disconnect any SCSI devices or SCSI PCI expansion cards and check for persistence of the issue.

Previous Mac OS X 10.4 (Tiger) Coverage: