Nik's Blog

Geekery, witty insights, software (of dubious quality) and more!

interarchy

Quick response on Interarchy

True to form, Matthew Drayton of Nolobe got an Interarchy bug fix out a few hours ago. Most, if not all, of the bugs have been addressed. This might be a good argument for the widespread use of public betas these days.

The new app is pretty slick. Running processes on remote servers is a killer feature if ever there was one. Having a terminal session open next to your FTP program does the same thing, but having it integrated so you can select files and pass them to the process is something else entirely.

Interarchy 10, Interarchy 9 all over again

Interarchy, my long-time FTP (and SFTP, and S3, etc…) client, just got a major upgrade. Now it’s at version 10. Among its many improvements is the ability to create plugins that run programs on the server you’re connected to! So you can, for example, edit your Apache virtual hosts files, and then bounce Apache without leaving Interarchy. Extremely cool stuff.

Unfortunately, it’s chock full of bugs!

These bugs range from irritations to full on crash the application bugs, and most are the kind that seem like they should have been detected in a very modest QA check. (One button in the preferences simply kills the app if it’s running under Snow Leopard!)

Interarchy 9 had an equally spotty release. I’m assuming that a 10.1 update will be here soon, but until then, there’s a painfully buggy program out there. On the up side, of course, I can keep using version 9, and wait until 10.1 to buy the upgrade. (if I choose to do so… Transmit’s looking great these days and has a lot to recommend itself)

Community and Independent Developers

This morning, I posted an article that was highly critical of Matthew Drayton’s management of the Interarchy file transfer application since he, as Nolobe, purchased it from the original developer. Specifically, I was frustrated with the lack of communication and shutting of communication channels between the big 9.0 release and the much-needed 9.01 bug fix which just came out.

Only a few hours after I posted this article, Matthew contacted me to apologize for the release and also to explain the circumstances which made a timely release of 9.01 impossible. As my criticism was both public and unjustified, I’ll apologize here, publicly, for this criticism. I have also unpublished that article.

However, beyond the specific criticism, it does demonstrate the importance of maintaining open communication with your customers. While most customers respond favorably to open communication, I think it’s especially important for small and independent companies, including independent software developers. This is probably even more important for independent developers who sell exclusively online, since their customers are much more likely to be part of the blogging/forum posting/twittering crowd.

People who purchase from independent developers act like grass roots supporters of a political campaign. Whether or not it’s justified, they feel that they are on a first-name basis with their favorite software’s developer, and they tend to especially watch new products from the same company.

This relationship is based on trust and communication. Those developers who actively maintain blogs, participate in forums, or who simply email quickly and responsively to requests can generate very passionate users. (Even if their software isn’t terribly high quality!)

Of course, those supporting customers come to count on this open communication. If it breaks down, it can leave customers feeling abandoned, and make them lose faith in the developer and their software. It can cause them to cease upgrading or even to defect to other programs. And, of course, there’s the beatings that an unresponsive developer can face on forums such as VersionTracker and MacUpdate.

What some developers overlook (and, again, I am not picking on Matthew here) is that this intimacy is a two way street. Just as the open communication helps users learn to use their software better, it is also a fantastic tool for priming the market for new updates and new products. And, perhaps even more importantly, it creates opportunities for the developer to get their users’ aid when they need it. Whether that’s a request for patience on an overdue update, advice on where to move web hosting to, or to gather a group of volunteer beta testers or even contributors. (documentation wiki, anyone?)

When Nolobe went “dark,” and stopped posting to blogs and pulled its forums, I lost confidence in the company and the software. I hadn’t upgraded to Interarchy 9 and was still using 8 until a less buggy version was available. Even though the developer was doing his utmost to get that 9.01 update out the door, it took a few months.

In the grand scheme of things, that isn’t much.

On the other hand, I’ve been using Interarchy (well, Anarchie and then Interarchy) for more than ten years. Seeing it change owners and then become unreliable on the next update is something else entirely.

Should Matthew have posted, at a minimum, a blog entry saying “It’ll come out later, please be patient?” It couldn’t have hurt. When a favorite restaurant is closed, you at least expect a sign saying when they’ll be open again – whether that’s tomorrow morning and you just caught them outside of business hours, or if it’s in a few weeks while they renovate.

Sometimes a person doesn’t even have the time or energy to even do that much. But for the users, the faithful supporters of a business, that note can mean everything.

Want proof? I just purchased the Interarchy 9 upgrade I’d been holding off on.

I didn’t buy it by way of apology for my undue critique. I bought it for two reasons: It fixed the bugs that made me hold off on the upgrade in the first place; and Matthew’s prompt and charitable email, even after my harsh criticism of Matthew himself – not just his software or his company. This email restored my faith in Matthew and Nolobe as stewards of one my mainstay programs. After all, what could be more personal and intimate than that personal email?

Ensuring trouble-free backups from your Mac to not-a-Mac

My current project is to enable network backups of my Mac and my wife’s PC over the internet, so that we have an off-site backup of last resort, should our house burn down, fall over, and then sink into the swamp.

Anyone who’s used a Mac for a long time knows that transferring Mac-native files over the internet is fraught with peril. You risk losing type and creator codes and resource forks, as well as a number of other forms of metadata introduced with MacOS X. So my first step was to determine how I could safely encode my files so that they could make the trip to a foreign server (which would either by a Linux-type box on my web host, or an Amazon S3 account) and then back again, with the file intact for recovery.

A few months ago, the Plasticsfuture blog ran an excellent article comparing the capabilities of darn near every backup and restore program on the Mac. The results were disheartening: Only SuperDuper! could precisely back up and restore a file (although, in my own testing, I found that ChronoSync was updated and can now handle the job).

However, my needs are somewhat different. A network backup requires that I only update changed files, and furthermore, I won’t be accessing them on a filesystem. So SuperDuper’s use of a disk image to perform network backups is straight out. So, too, is ChronoSync, since it can only back up to a network filesystem.

No, I need something that can encode individual files, ideally via a script or some other automated method. Furthermore, I’m mostly just concerned about archiving documents (I don’t want to pay for online storage of my whole hard drive!), so if permissions, ACLs (which I don’t use), or BSD flags are munged, that’s all right. This is truly a last-resort backup, so if I can get resource forks and extended attributes to back up, I’m pretty happy.

Now, according to Apple, a number of command-line utilities have been updated to deal correctly with extended attributes and resource forks – these include tar, cpio, ditto, and zip. There are also a handful of third-party archivers/compressors out there which also claim Mac compatibility such as the x7z (a Mac version of the 7-zip compression algorithm) and StuffIt compression programs, the xar archiver, and Interarchy’s “backup” format. (Note: Interarchy’s backup page is currently 404’ing, but suffice to say it’s an open format that attempts to encode files in such a way as to store all of Apple’s fancy metadata.)

So I figured I’d do what any red-blooded geek would do, and test all these programs to see if they did what they claimed to do. My test was pretty simple: I took a text file, assigned a Finder label and some comments, and added a resource fork and some custom extended attributes. If all these things made it through intact, I’d consider the tool good enough for my purposes.

The results were interesting. First off, every program I tested successfully maintained the resource fork, which is really the most important part of the file to keep around. Additionally, every program except for tar managed to keep the Finder label. As for extended attributes, only tar, the Interarchy backup format and cpio successfully kept the custom extended attributes. This is especially baffling given that the resource fork in MacOS X 10.4 is nothing more than an extended attribute!

The most troubling thing for me was that none of the programs I tested managed to maintain the “Spotlight Comments” I’d added. I frequently use these comments as a way to tag my files for Spotlight searching, so their loss is somewhat problematic. It turns out that these spotlight comments are stored in the invisible .DS_Store file in the same folder as the file I was backing up. So provided I restored (and backed up) the whole folder, that wouldn’t be a problem. Still, it would be nice to see it handle all that.

Update: I hadn’t originally tested it, since Apple hadn’t listed it on their OS X pages as a utility that had been updated to work with resource forks, but some online discussions led me to believe that the pax archiver had also been updated. Indeed, it has, and it successfully maintains resource forks, extended attributes, and Finder labels, just like cpio. It does, however, seem to have bugs when used on systems with ACLs enabled, and like everything else, it loses Finder comments. I have updated the discussion, below, accordingly.

So this leaves me with three solid options: The Interarchy Backup format, pax, and cpio archives. The latter two archive formats are fully compatible with other unix-like systems and can even be expanded using the graphical BOMArchiveHelper on the Mac, so they may be the best choice. Both archivers permit me to compress files in the archive, which is a nice bonus for network archiving. Of the two, pax has some nice advantages, including a larger file size limit on archives and some interesting command-line tricks including the ability to write out to different archive types. Cpio, on the other hand, seems to work on systems with ACLs enabled.

However, I suspect (although I haven’t tested this) that the Interarchy Backup format captures more Mac-specific metadata, since it was designed with exactly that goal in mind, and Apple’s programs are, well, less than entirely consistent in supporting these filesystem features. I do wish Apple could at least provide tools that were consistent and reliable.

It is worthwhile to note that none of the graphical Mac compression utilities managed to maintain extended attributes, not even Apple’s customer zip archiver (which is the same tool used when you archive files in the Finder) nor StuffIt, which has long been a Mac-friendly standby compression program. This leaves Mac users with essentially no easy options for compressing files prior to emailing them or posting them to an FTP site other than disk images (which aren’t cross-platform).

I’m disappointed that the xar archiver, which was designed precisely to handle metadata schemes on different systems, didn’t perform better. It is still a work in progress, so I left some bug reports, and I remain hopeful they will properly support extended attributes and comments in future releases. Since xar can also handle compression as well as encryption, it would be a fantastic solution for off-site backups.

Soon I’ll post how my backup system develops and works over the long-term. If you have any questions or comments, please feel free to sound off, below!

Subscribe to RSS - interarchy

@inik

inik: RT @thinkprogress: .@komenforthecure head says responses to Planned Parenthood decision are "very favorable." If your response is unfavo ... >
inik: @FluidApp I'm getting errors in a Fluid app Gmail and can't use chat either. Any ideas? >
inik: finished Five Children and It by E. (Edith) Nesbit et al. and gave it 5 stars http://t.co/mspysk1B #Kindle >
inik: How to use an obscure shell command to let your AppleScripts and shell scripts output rich text. http://t.co/3Y9dAHiH >
inik: Nicholas "Nik" Friedman TeBockhorst http://t.co/I6kGmcDg >

Google+

I love Seth's quote at the top. I think that's my new motto.. ; )

Powered by Plu.sr
>
Griping about OS X Lion? Here's two nifty tools that replace a variety of poorly supported third party tools: Command-line and Automator access to video and audio conversion. Super easy to use, and very flexible and supports any format that Quicktime can encode/decode. (So Perian is a must-install if you want to handle DivX/3viX, etc.)

Yes, ffmpeg, Handbrake and...
>
Fix Google Reader's horrible new interface with this user script! Now it fits nicely on my MacBook's small screen. >
Happy 11/11/11 11:11:11! >
What makes this ad awesome is not the true-to-life irony, because the idea is hardly innovative, but rather the excellent execution. Reminds me a bit of that excellent Nutri-Grain spec commercial. Quick delivery, good actors, hit all the high notes. Love it. >