Playing hopscotch around the third rail

Playing hopscotch around the third rail

Hmm, yes, I seem to have discovered another "third rail" topic. It's funny, right, as long as I say that everything is fine with my Mac, all is well. However, the instant I start reporting that I'm going "out of phase" with the way Apple seems to want to be now, the haters emerge.

Now, granted, most of the comments I've seen have been fair and level-headed, even when they didn't agree with me. I don't mind if you disagree. I actually like reasonable disagreements since they tend to keep me honest. That's how I learn stuff and fix bugs in my head.

No, what's really awesome are the messages which are unfounded. I'll respond to some of them or clarify points which might not have been completely obvious in yesterday's post.

Apparently I'm not a coder on the Mac. Hmm. I hate to tell you this, but there's a tree full of source code which disagrees with you. It's almost all C++, and it's effectively portable, as it should be. That is, I can build and run it on my Macs or on my different flavors of Linux boxes.

This post is coming to you through a program I call publog, and its entire existence has been on my Mac laptop. I edit a plain text file, run it through the publog generator, and rsync it to my web server.

I even run software-defined radio code on my Macs. Yes, I'm talking about GNU Radio and the RTLSDR sticks. I've used them to fill in for my production system (the Linux box with a USRP) when said box was taken down for maintenance or upgrades. This is non-trivial technology!

I hit weird problems. gprof doesn't work. It's probably due to the use of clang vs. gcc. There are other tools, but nothing I've found behaves like gprof and spits out the numbers I need.

gcov didn't work in Snow Leopard. I actually found a workaround for that and published it. I've gotten feedback from some people thanking me for doing exactly that, since they hit the same problem and really needed it to work.

I think some of these haters are going to need to prove they can do a "drill down to the C library" debugging session before they start challenging my coding ability or technical credentials.

People can't make up their minds as to whether it's supposed to be just another Unix box or whether treating it like a Unix box is stupid. Yes, on the one hand, there's this:

Your Mac is a fellow Unix machine. Start using it as one, and your transition to Linux is a piece of cake.

But, there's also this:

Why do you insist on tackling any problem that you encounter with exactly the same toolchain and/or mindset that you would on Linux?

Basically, I'm screwed no matter what I do. They will find some way to label me that fits with their agenda of thinking I'm stupid.

Well, if that amuses you, okay, fine then. Couldn't you fill up your Saturday afternoon some other way? Go throw rocks at cars, or something.

People say I should just copy the raw directories from iTunes and iPhoto and I will find all of my data right there. Really? Let's just see at what an iPhoto directory really looks like.

mbp:iPhoto Library rachel$ ls -1
AlbumData.xml
Attachments
Auto Import
Backup
Caches
Contents
Data
Data.noindex
Database
Info.plist
Library.data
Library.iPhoto
Library6.iPhoto
Masters
Modified
Originals
Previews
ProjectDBVersion.plist
Projects.db
ThemeCache
Thumbnails
iLifeShared
iPhoto.ipspot
iPhotoAux.db
iPhotoLock.data
iPhotoMain.db
iPhotoMain.db-(snip)
iPod Photo Cache

Some of these look promising. AlbumData.xml is 31 MB, and it's XML as the name suggests. Projects.db is 589 KB and it's a SQLite 3.x database according to "file".

Data is a symlink to Data.noindex. Data.noindex is a symlink to Thumbnails.

So, here's the question: can I find an arbitrary picture from 1990 which was given geographic location information? This picture does NOT have EXIF data, given that it was a Real Picture at some point in time and was scanned in. It was brought over to iPhoto at some later point, probably 2009 or 2010. Then I tagged it with the location where it occurred and also filled in the date based on what was written on the back.

The Thumbnails directory has a bunch of things with years in them, but none of them start with 1990. They all seem to be 1996 and newer, plus one from 1969 which almost certainly implies a Unix time_t of 0.

So I do a "find" and grep for 1990. I find something potentially interesting: a directory called "./Database/Versions/1990/01/12". I ^C the find and check it out, since that's the right date. I jump into that directory, then into another subdirectory called 19900112-010833, and then another subdirectory which appears to be a random string of letters, numbers and the % sign.

At this level I find three files:

-rw-r--r--  1 rachel  staff   901 May 15  2012 Master.apmaster
-rw-r--r--  1 rachel  staff  1674 May 15  2012 Version-0.apversion
-rw-r--r--@ 1 rachel  staff  2319 Feb 23 16:08 Version-1.apversion

According to "file", they are type "Apple binary property list".

So, okay, that's not my picture.

I let "find" run to completion in the other paths and turn up a few interesting things. What's this?

./Masters/2004/12_8/ab05-19900112.jpg

Now, it just so turns out that this picture had a unique filename. When I scanned it in way back when, I called it "ab05-19900112". I think it was the fifth photo (05) scanned in the second batch of scans I did (ab), and it had a known date.

That file is in fact my image. What it's doing in "2004/12_8", I may never know. It has a mtime of August 21, 2009, which is probably when I first brought this picture over to iPhoto.

There's also one in Thumbnails, and it's a smaller version as you would expect.

Neither image has EXIF data with the date or location in it. iPhoto is clearly storing that stuff somewhere else.

The question is... where?

I go into AlbumData.xml, and by searching for "ab05-19900112", I find something promising. There's a blob called a dict which has a bunch of things. One of them is "ImagePath", and it's the full path to the /Masters/2004/12_8/... thing as shown above. It also has "ThumbPath" which is the full path to the Thumbnails. Okay so far.

Then, there it is: latitude and longitude, with plausible numbers.

I don't know how I'm supposed to get "January 12, 1990" back from "ModDateAsTimerInterval" when that value is 125053699.000000. That's not enough seconds to be a Unix time_t value. Even worse, the "DateAsTimerInterval" is negative: -348331901.000000. Negative time?

Okay, so that date in 1990 is 348 million ... somethings ... before something else?

As it turns out, the epoch in those files is January 1, 2001, or 978307200. I had to grovel around the web to find that. It still doesn't give me quite the right value, so there's something incomplete in my knowledge so far. This brings up another point.

How much time have I blown on this already just to get this far, and how much more will I blow to get the rest of the way? This right here is the false economy of the carefree days I had in the past, and thus the entire basis of my original "mortgaging my future" premise.

I'm not sure I want to know what happens when I try this for a picture without a unique filename. How many IMG_0001.JPG files can there be? If you've been through a couple of phones and digital cameras in the past 13 years, probably quite a few.

To those who still don't get it, you do realize I said I mortgaged my future, right? This isn't about you and how well it'll work for you. It's about me and the mistakes I've made.

If it works for you, great! Why that supposedly invalidates my experience, I may never know.