Time Machine Thinks All Iomega Drives Are The Same

A colleague purchased two Iomega 500GB eGo portable hard drives at the Apple Store to use with his new MacBook Pro 15″.  He set up one drive to be a Time Machine backup drive (Backup) and the other as external data storage (Datastore).  The problem was whenever he plugged in Datastore the MacBook Pro treated it like Backup and would proceed to backup to Datastore – the incorrect disk.  I tried some draconian methods – deleting the .com.apple.timemachine.support, .fseventsd, and the sparsebundle, but Time Machine kept using Datastore every time I plugged it in.  This is in addition to Time Machine using Backup every time it was plugged in.

I fixed the problem by deleting the partition with Disk Utility and recreating the disk partition.  I believe Iomega has made a mistake in the way they make this product the “Mac Edition”.  My theory is they are imaging the drive with the same blank image.  This image contains the token Time Machine uses to identify “what drive is this?” (Time Machine doesn’t use volume name).  This results in Time Machine seeing every drive in this product line as the same drive.  When you make a new partition, the drive’s identity token is deleted and a new one created – problem solved.

Details

  • Iomega 500GB eGo FireWire/USB 2.0 Portable Hard Drive, Mac Edition
  • Apple’s web site says “Mfr. Part No.: 34629” but the underside of the unit says Model No: RPHD-TG.
  • Mac OS X 10.5.8
  • Iomega creates the partition with Apple Partition Map.  When I recreated the partition I used GUID Partition Table
  • The USB Serial Number as shown in Disk Utility was different for each drive when plugged in so this isn’t the token.
  • These units also can connect via Firewire 800 which we were doing.  Firewire devices have a Connect ID in Disk Utility.
  • Having one drive plugged in via Firewire and one plugged in via USB had no affect on this problem – it failed just the same.

Eclipse and Version Control (SVN)

My C++ project is now in Fedora Eclipse (Version: 3.4.1 Based on build id:  20080911-1700) and the perennial question comes up…

Q: What files am I required to checkin to version control (SVN)?
A: .cproject and .project

If you are testing the checkin on your machine there is one caveat. Delete the project from the Project Explorer. Then use the Import command from the File menu. This process will create some of the temporary files that were not checked-in but expected to be there when building the project.

Boa on Fedora 11 Fail

Tried for 3 days to get Boa working on a clean Fedora 11 install. Four VMs failed. The only machine it works on is a crusty Fedora 11 image installed on physical hardware. Failure mode is service boa start returns with [Failed]. Nothing in the logs. After editing the init.d/boa file to output more info we still don’t see anything. Going back to Fedora 10 VM.

Update: Submitted bug 527582 to RedHat.

Confusing Yum Error

Yum in Fedora 11 could use some work on error reporting.  While I have no doubt the following message was technically true – it wasn’t very helpful in diagnosing the problem.  This failure was caused by the loss of Internet connectivity.

Errors were encountered while downloading packages.
boa-0.94.14-0.12.rc21.fc11.i586: Caching enabled but no local cache of
/var/cache/yum/fedora/packages/boa-0.94.14-0.12.rc21.fc11.i586.rpm
from fedora