Sunday, September 03, 2006

iPhoto: what remains when you delete every image?

I'm working on a peculiar iPhoto 6 bug, and one of my experiments meant I deleted every image in a 11.5GB iPhoto Library. I was surprised to find that, with every image deleted, the empty Library was 792MB.

I dissected the remainders until I got the empty Library to 5.8MB. Here's what remained:
Thumb*.data: 125MB - when you delete images iPhoto does not necessarily clean up the thumb caches. These can be safely deleted.

iPod Photo Cache: 580MB - this is what goes on my iPod. It wasn't removed when I deleted all the iPhoto images.

2004: 75MB (41 photos)
and
2005: 2.3MB (1 photo)

I think these are left over folders from when I moved from iPhoto 5 to iPhoto 6. They probably hold images that remained after everything else was relocated. Interestingly iPhoto never produced any error messages about these residual images. I think they were all images I deleted that somehow didn't get removed properly.

Originals: 2 photos only remained in my Originals folder, apparent duplicates two of the images in the 2004 folder.

The final residual: 5.8MB
I'm going to take the 45 images I recovered and compare them to the images in my main Library. I'll provide as an update to this post.

Friday, September 01, 2006

When OS X Disk Utility Fails: Error code -9972

From Apple’s KB:

Disk Utility reports \Underlying

... In rare circumstances, Disk Utility may display the following message when you try to repair a disk:

"The underlying task reported failure"

The Disk Utility log will also display a -9972 error code. This indicates that your disk volume has issues that Disk Utility cannot fix.
What can I do?…

…. For Mac OS X 10.4.6 or earlier: If you have Adobe Photoshop CS2 or Adobe Illustrator CS2 installed, try removing the following files:

* /Applications/Adobe Photoshop CS2/Legal.localized/Tie??ng Vie??t.html
* /Applications/Adobe Illustrator CS2/Legal.localized/Tie??ng Vie??t.html ...

Basically this error means you’re probably doomed and should have good backups. Note, however, the curious Adobe related bug. I bet that one’s quite interesting.

Nasty OS X design flaw: Spotlight and sleep

This was taken from a good OS X tech article on why a machine might not stay asleep. One item stood out.
Mac OS X: Why your Mac might not sleep or stay in sleep mode: "Spotlight

... Your computer will not sleep if Spotlight is indexing content, because that requires hard disk access. For example, if you just installed or reinstalled Mac OS X, Spotlight may need a while to index content...
Wow. That's one heck of a design flaw -- more than a mere bug. This may explain all those dead laptop drives from owners who closed their new MacBook, stuck it their bag, and expected it to sleep. If Spotlight was at work in the background, the machine won't sleep.

Dumb.

An exceptional list of Windows developer tools and resources

It’s from a Windows developer (.NET), but a very useful list for those of us who must occasionally dwell in XP.

Scott Hanselman's Computer Zen - Scott Hanselman's 2006 Ultimate Developer and Power Users Tool List for Windows

He likes the Notepad2 or Notepad++ text editors. I still use TextPad myself — but that’s probably from inertia.

Thursday, August 31, 2006

Dans Data on affordable NAS solutions

Now that NetGear has added spindown, Dan likes them:
Inching toward the NAS of our dreams

When Netgear's SC101 Storage Central box first came out, I was hopeful. It accepts one or two PATA drives, does not come with them pre-installed, can run them as individuals or in mirrored mode, even allows volume spanning across multiple units, has easy setup, and, as I write this, it costs less than $AU200 delivered (rather less, in the States).

But then I cursed Netgear unto the seventh generation, for lo, the box did not spin down its drives.

But then, behold, there came BIOS updates, and one of them added spindown. Glory be.
Alas, it's PC only.

Drive spindown and lifespan

The world's best hardware site talks about why consumer drives live 2-3 years ...
The USB drive time bomb

...In a typical business-computer situation, where the skinflints in the purchasing department have made sure that every PC in the place is short of physical memory and so flogs its drive non-stop for eight hours a day, a substantial fraction of those drives can be expected to last two years or less. Three is definitely pushing it. Support people in such companies are used to doing drive replacements, and would probably have to do significantly fewer if the computers had more RAM.

People with the misfortune to have bought a base-spec Dell desktop are in the same situation, but so are a lot of geeks, who make up for their ample system RAM by spending a lot more time in front of the computer doing stuff that hits the disk. Heck, just downloading all that video will stop the disk receiving it from ever spinning down.

The way you make consumer drives last is by not using them. If they're spun down in standby mode, they're not wearing out. Even if a drive's kept in an anti-static bag in a cupboard, it won't last forever, but it's usually the physical components like the spindle and head assembly bearings that kill a drive after two years. When they ain't movin', they ain't wearin'.

Getting hard drives to spin down on any modern computer is, of course, easy. You can set the spin-down time to a really aggressive laptop-on-batteries five minutes or so, if you like. Consumer drives spin up fast (server drives don't), so there's no huge performance penalty to pay for doing that.

But if you're using USB drive boxes, their own little bridge interface is what decides when the drive spins down. Or, more accurately, if the drive spins down....
I destroyed an iBook drive by basically using it like a server drive for 3 years. No hard feelings, I flogged that beastie.

I haven't paid enough attention to spin-down in external drive units. Mea Culpa. Now we all know better ...

Wednesday, August 30, 2006

iPhoto 6 bug: flaky 'revert to original'

Update 10/26/07: iLife 2008 (iPhoto 7.1) has fixed this bug.

iPhoto is supposed to keep an original image untouched. Edits are applied to a copy. The originals live in one folder hierarchy, modified images in another. If an image is edited, iPhoto shows a 'revert to original' option.

That's the theory.

In my case an attempt to merge iPhoto Libraries using iPhoto Library Manager uncovered hundreds of images that are flaky in my the iPhoto Library database. The images themselves are fine. They're in the Originals folder. They really have no 'modified' equivalents. However, iPhoto "thinks" they have modified versions.

In other words, this Library is infested by phantom "modified" images. They don't exist, but iPhoto thinks they exist, so it shows me the 'revert to original' option when it shouldn't. By itself that's a cosmetic issue, but I think this is causing problems with several secondary products, especially with iPhoto Library Manager but possibly also PictureSync.

Selecting 'revert to original' does nothing. (This is good, in earlier versions of iPhoto this action would sometimes DELETE the original.)

I should note I've never used 'iPhoto Diet' or anything like that and I've never messed with my originals within iPhoto. This is the inverse of the known problem where a modified photo exists but the Original has been lost, moved, or deleted.

If I edit an image, then 'revert to original', the reversion works properly. After reverting the option is (correctly) grayed out in iPhoto and unavailable.

These are older images, exposed to nasty bugs in many prior versions of iPhoto. This Library may date back to iPhoto 2 and was certainly exposed to the many iPhoto 4 bugs.

I think iPhoto 6 is a decent product, but it follows a long line of disastrous releases. I would never claim Apple releases well tested products.

Alas, a Google search and a Sherlock search of the knowledge base didn't turn up anything useful. I've asked the author of IPLM for advice and I'll update this posting with what I learn.

Updates:
  1. I did a complete rebuild of my iPhoto Library. The good news is that the rebuild didn't turn up any bad images and the rebuilt library tracked the original pretty well. As usual the rebuild messed up roll metadata. Since it didn't fix the problem I deleted the rebuilt Library.
  2. I have a theory this problem arises when one uses the burn-to-CD or IPHOTO.XML method to merge iPhoto Libraries. iPhoto imports the Original and Modified files correctly, but there's a bug with unmodified Originals that leads to the above problems. (PS. I doubt this merge technique works at all well with RAW files.)
Update 9/1:

Wow, this is a gnarly bug. Brian Webster of IPLM fame is helping debug what's happening and I've gotten some useful comments from the iPhoto Discussion area:

Here's a comment I posted to the discussion thread:
... I tested a (risky) variant of the 'import from iPhoto CD' technique documented here:

http://www.faughnan.com/digcam.html#LibraryMerge

I did the same import twice, once on a brand new iPhoto Library and again on my main Library with the known problem.

When I imported into a new Library there were no problems with the 'revert to original' -- everything behaved as it should. Revert to Original only showed up when an image had been modified.

However, when I repeated the exact same import into my problematic Library every image had the 'revert to original' option available -- whether the image had been modified or not.

On the other hand, directly importing from the file system into my problematic Library didn't produce the bug.

So it's a combination of something about this Library and something about the undocumented Library import I tested with. I've yet to test with the semi-documented "import from iPhoto CD" method with this Library but I may try tomorrow. I'm also going to test using the 'import via shared albums method Pogue and Story document in 'iPhoto 6 The Missing Manual'. My suspicion is that all methods will produce the same problems with this particular Library...
Update 9/3:

I tried the partial merge technique published by Story and Pogue -- sharing a Library from another account. I imported into my "bad" Library and it did NOT (so far) demonstrate the 'Revert to Original' bug.

Update 9/14/06:

Brian Webster sent me a new version of IPLM to beta test. It no longer gave the 'missing image' message but there was interesting new flakiness with Library Rebuild. Library Merge seemed to work 3/4 tries, but 1/4 times it made an error consistent with the Library Rebuild problems. So whatever this bug is, it's darned sneaky.

Update 10/4/06:

We never figured this out, but I'm pleased to report the bug does not appear to confuse Aperture 1.5. It imported my test Library correctly.

Update 5/18/07:

Tom, writing in comments, discovers where the bug is. I'll tell Brian and post in Apple forums:
This week I converted to iPhoto6 and encountered the same problem. Some older photo's have the "revert to original". I examined the file Library6.iPhoto and concluded that the conversion of a field "idED" went wrong. I was able to repair the file using a HEX editor.
Thanks Tom!