Coordinated CoCo Conference #1

In late October of 2010 Aaron Wolfe, Todd Wallace and I decided to try to hold a monthly Color Computer Conference in the internet. We tested TalkShoe and Mumble as platforms to use, but decided to use Skype for the first conference.
We announced the first call would help held Tuesday, November 2, 2010.
I am very pleased with how the first conference turned out. I am posting the audio as an attachment to this post. Please enjoy: Coordinated CoCo Conference #1.mp3.
The next conference will be held early in December.

Dating

15 Year Old Daughter: “What’s wrong with me dating an 18 year old?”

Me: “Remember when I was teaching you how to drive? Before you pressed the break for the first time, I said, ‘Now press the break pedal gently.’ And the car immediately came to a jarring halt. And you asked, ‘How come you didn’t warn me that would happen?’ And I said, ‘There is no way I could have warned you what kind of pressure was needed to properly stop a car going 10 miles per hour. It’s something you have to experience yourself.’

15 Year Old Daughter: “Yeah.”

Me: “That’s what it is going to feel like years from now when you look back at dating an 18 year old”.

Mac OS X core utility Find and Extended Attributes

I’ve been writing backup scripts recently. I really like rsync and have been using it with Mac OS X’s smbfs quite successfully (under 10.5). But the other day I found some files that were created on the receiving file system but contained no data.

I really wanted to know how pervasive this was so I asked find to list the files that are zero bytes long. Needless to say I got a lot of false positives. It is not uncommon for the files I use to have zero bytes in the data fork. Usually these files will have some data in their resource fork. The find command only looks for data in the data fork. Files with zero bytes in both forks are rare and those are the files I needed to find.

I needed to change the behavior of find. Finding and compiling the source code for find was easy. My first thought was to add up all of the extended attributes each file has and use that as the total file size:

75a76

> #include <sys/xattr.h>

1428c1429,1453

< off_t size;

---

> off_t size, calc_size;

>    ssize_t list_size;

>    

>    calc_size = entry->fts_statp->st_size;

>    

>    /* get list of extended attribute names */

>    list_size = listxattr(entry->fts_path, NULL, 0, XATTR_NOFOLLOW);

>    

>    if( list_size > 0 )

>    {

>       char *namebuf, *current_name;

>       namebuf = malloc( list_size );

>       listxattr(entry->fts_path, namebuf, list_size, XATTR_NOFOLLOW);

>       current_name = namebuf;

>       

>       /* iterate over list of extended attribute names */

>       

>       while( current_name < namebuf+list_size )

>       {

>          calc_size += getxattr(entry->fts_path, current_name, NULL, 0, 0, XATTR_NOFOLLOW);

>          current_name += strlen(current_name) + 1;

>       }

>      

>       free( namebuf );

>    }

1430,1431c1455

< size = divsize ? (entry->fts_statp->st_size + FIND_SIZE - 1) /

<     FIND_SIZE : entry->fts_statp->st_size;

---

> size = divsize ? (calc_size + FIND_SIZE - 1) / FIND_SIZE : calc_size;

This worked well enough for my needs. Although it has some problems. The biggest one is that it doesn’t produce files sizes that match the Finder’s get info dialog box. It seems the Finder only adds the data fork with the resource fork. Where as the code above adds every available extended attribute. Common additional extended attributes include “com.apple.quarantine” and “com.apple.FinderInfo”.

Blocks

I’d like to introduce you to Blocks. It’s an application I’ve had in my mind for a very long time. At it’s basic level it is about understanding data formats. Very geeky stuff.

I finally have something to show, so I’d like to tease you all with the folowing Quicktime screen cast:

http://www.macmess.org/downloads/Blocks_Screen_Cast_A.mov

I plan on more screen casts so show more functionality. Please, let me know what you think.

Here you find where I first write my thought down about all this. It’s interesting how the idea has changed since then.

Reoccurring Apple PubSub requests in my Apache logs

Frequently in my web servers logs I would see a request for an RSS feed I have available from a “PubSub” user agent from my IP address. It bothered me because the feedreader I use doesn’t use Apple’s PubSub library to read feeds.

So I figured Safari was the cause. I had tested Safari’s RSS support a long time ago, but didn’t like it. I took a quick look and found Safari was subscribed to zero feeds. Hmm. After some web searching I discovered the pubsub command line app Apple provides to manage the resource.

I told it to list all the feeds it knows about and sure enough, there was the offending URL plus some others. I promptly deleted them from the list. I figured all was well. But after a few hours, I found new log entries for the for the same feed. I queried the PubSub command again and found all of the entries restored. I discovered Safari would restore the feeds every time it launched. Safari’s GUI was no help. I looked everywhere for entries for the feeds and found nothing. So I started combing thru it’s preference files.

I finally found the feeds listed in the “TopSites.plist” file. The GUI displaying the top site in Safari did not list these feeds. Strange.

I used the plist editor to delete the references to the feeds in the top sites preference file, and now Safari no long repopulates PubSub. Happy days indeed.