I’m co-leading a kayak trip in Providence this Sunday, June 26, with the AMC Narragansett Young Members. If you’d like to sign up, we have available spots and a few kayaks for cheap rental. Since it isn’t a purely flatwater trip, you should be comfortable with sitting in a kayak, but don’t need a lot of experience in order to enjoy it.

You can sign up online.

Trip description:

We’ll spend time enjoying downtown Providence from the river, and also paddle outside the Hurricane Barrier to get a taste of Narragansett Bay. Not literally. L Bev Thomas, CL Andrew Shearer. The route is similar to the one in these pictures.

fs2svn is a new, free, open-source tool that converts a bunch of archive folders into a Subversion repository.

If you’ve kept a series of historical snapshots of your work in folders, fs2svn can help you upgrade to a full-fledged version control system.

fs2svn goes through all the folders under a given parent folder (in filesystem order) and creates a Subversion revision for each one, backdated to the most recent file’s last modified date. The log message is set to the folder name.

Additions, changes, and deletions between one folder and the next are all recorded in the repository.

The input format is very simple. It only covers the mainline trunk, not any tags or branches (though tags for major versions could be manually created later, if your folder names carry enough information).

The format is so simple it could be used as a common intermediary. If you wanted to migrate a mainline trunk from some exotic version control system to Subversion, you could write a script to export it to regular folders, then use this script to import the result into Subversion.

See the main fs2svn page for information, examples, and to download.

Congratulations to my father and my brother Rob, who just finished sailing back from Bermuda to Newport in the double-handed leg of the Bermuda 1-2 race. I still don’t know how they placed officially.

(This is the race I’d done the past few times as the crew, with my father as captain, for the double-handed return leg. The inital Newport-to-Bermuda leg is single-handed, so he of course does it alone.)

The first leg involved two emergencies where my father’s boat started filling with water. I still haven’t heard all the details, but it turned out not to be a real leak. For the return leg, one boat was dismasted, but they managed to rig up something to get to shore. No major disasters like the 2003 race, where one boat capsized, and the crew was picked out of the water by a passing cruise ship.

I had a problem where my scripted FTP uploads through ftplib in Python 2.3 would experience long (6 or 7-second) delays before transferring each file. Other FTP programs were fine, except for a similar delay on connect. It turned out to be an interaction with ftplib’s IPv6 support in Python 2.3 and the Mac OS X name resolver, and it finally appears to be fixed in the recently-released Mac OS X 10.3.8, which noted speed improvements in certain network applications.

In case the delay bites anyone else (or in case it’s not really fixed, and some other network change is just fooling me) here’s the workaround I’ve been using until now.

With IPv6 support in Python 2.3 / Mac OS X 10.3, ftplib’s ntransfer function now calls getaddrinfo for every single file tranferred, and the name resolver does a slow timeout each time. Making a local copy of ftplib and replacing the call to getaddrinfo with constants may be ugly, but it worked around the problem.

Original line (multi-second delay), at ftplib.py line 233:

af, socktype, proto, canon, sa = socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM)[0]

Changed line (assumes IPv4 addresses):

af, socktype, proto, canon, sa = (2, 1, 6, '', (host, port))

This change speeds up multi-file FTP transfers immensely (at least to my FTP server) under Mac OS X 10.3.0 through 10.3.7, but early results indicate it’s not necessary on 10.3.8.

Why does Windows still suck?

The most surprising figure in the article–that 91% of PCs are infected (or maybe the word should be “infested”)–sounds high, but gets some anecdotal support in comments in Brent Simmons’ weblog.

The fact that you’re reading this means the server move was successful.

Bill Bumgarner’s useful Dupinator script, for removing duplicate files, recently hit Python-URL. However, it has a logic bug that end up deleting too many files.

If you have several sets of duplicates that happen to share the same file size, all but one of the sets will be wiped out completely. The problem is that within each group of files of identical size, there’s at most a single generated “duplicates” list. The first file on the list is spared; the rest are deleted.

The net effect, when I tested the script on a large corpus of text files, was the program reported it would delete many files that were clearly not identical. (I had commented out the os.remove call for testing.)

There was an additional problem with iPhoto: the posted script follows symbolic links. iPhoto stores its albums as collections of symbolic links, so all photos in albums are flagged as duplicates of the original photos. An islink() test fixes this.

Here’s a modified version of the script. It has only been lightly tested, though the changes did successfully eliminate the false positives. Uncomment the os.remove() line only when you are satisfied with the list of redundant files generated.

Minor optimizations: all files < = 1024 bytes go directly into the dupes list, not potentialDupes, since the whole file has already been checked. Also, Mac OS X’s pesky .DS_Store files are skipped.

(I haven’t heard back from Bill yet on incorporating the fixes into his code, so I’m posting here.)

View Source Code (dupinator.py)