About | Buy | Forum | Industry Watch | Learning Curve | Products | Search | Twitter | Xnews
Home » Products » Reviews » The Bad

FTP Clients

A good FTP client is essential for website maintenance. Unfortunately, the world of the Mac suffers from being seriously behind the time.

Before venturing out to see what the world has to offer, we should arrive at an understanding of what a good FTP client is.

An FTP client is understood in this context to mean a GUI client - that is, an FTP client with a graphical interface. The FTP protocol is itself well documented, and all personal computer systems, from Unix to Windows, have a command line FTP tool.

What makes the GUI client essential is the ability to aggregate uploads and downloads, so that the user does not have to recurse through all possible directories to synchronize a web site with the local update. A GUI client will interface with the FTP protocol, parsing output from the remote FTP server, displaying this information in the graphical interface, accepting user input, and transforming this input into commands conformant with the protocol.

The basics of FTP are already in place: the RFCs and local source code give the development team all they need here. What is necessary is to organize this code into something useful.

A good FTP client will be designed not only for downloading files, but even more importantly for uploading files. It will offer side-by-side listings of files on both the local machine and the remote server. And it will of course be virtually bug-free and eminently stable.

A good FTP client must understand the FTP protocol: it must understand the transfer modes used by the protocol, and it must understand the 'world of Unix'.

Fetch

Our journey starts with a look at what was once a standard in the world of the Macintosh. Originally freeware written at a major US university, Fetch is today a commercial product, yet it exhibits none of the traits of a useful FTP client.

There was once a time, before the dawn of the Internet, when the tiny world of Macintosh was all a Mac user ever needed. Macintosh developed a number of strange file formats, partly based on the distance from the 'ordinary' computing community, and partly because of the wacky file systems in use. Things like binhex files came about in this era.

But the Internet changed everything. Unix servers dominate the web, and Unix thinking and Unix architecture steer its use and further development. The FTP protocol becomes the end-all for FTP use. Yet the world of Macintosh - at least as evidenced by Fetch - never took notice and never caught up.

Fetch suffers, as many of these clients, from a total lack of realisation that the local file listings are important too; that people may be using the program not so much to download files, as to upload them.

Fetch offers a single listing of the remote server you log into; for file transfers, you get to look at the standard OS X Open and Save As dialog boxes. Thus to have any understanding of what you are doing, you need to have at least one more program (Finder) open at the same time, and make sure both programs are fully synchronized. It's all too confusing and much too much work.

Fetch offers several Macintosh transfer formats, but neither of the two formats used in FTP.

While the program itself seems stable enough, the lack of conformity with FTP and a proper design make it a bad choice.

Interarchy

Interarchy is the favorite FTP client of a lot of Mac die-hards. One has to wonder what these people use FTP for.

Interarchy has a design very similar to that of Fetch: they are both totally unfathomable. There is no side-by-side listing of files; local file operations have to be done through the Finder; and so on.

But Fetch is at least tasteful in its ineptitude: it is a cute little program with a user interface that is easy to manage and which coexists nicely with other programs on the desktop.

In contrast, Interarchy is big, bloated, unwieldy, unmanageable, and totally confusing. There are windows which will open and consume an entire screen width of 1024 pixels or more - for what reason is not known, as the data in the windows is totally irrelevant and useless. And there are bugs - heaps of them. Interarchy suffers from being a bad design shoddily implemented.

What really puts the icing on the cake is the price: you have to pay around US$50 for this monstrosity. Save your money.

Transmit

Transmit is the best of the FTP clients for OS X. In fact, it is the only client with the right idea. It uses a known FTP engine; it has listings side by side of both the local and the remote files; and under Aqua it looks really good. Unfortunately it suffers from a number of bugs which makes the task of shelling out money a bit distasteful.

The Transmit programmers are aware of the bugs in their program, but no information has been forthcoming about when users can expect them to be fixed. As things stand, the most appropriate action is to inform the Transmit team that you will not be paying for the application until the issues are resolved. (The reader may wish to extend the stressful 15 day trial period under these circumstances.)

In a nutshell, Transmit suffers from what so many OS X apps suffer from: clueless programmers. Programmers who have never had to write critical real world applications. Clueless programmers who don't think things through properly (or at all), who rarely if ever test their ideas, much less their products, and who walk around through life wearing rose colored glasses. Programmers who know nothing about defensive programming. Programmers who don't belong. And so on.

Getting a Clue

Try this on for size: fire up Transmit and focus on the left pane - 'your stuff'. Find the command to create a new directory. Name this directory 'Clueless'. Notice how Transmit puts this directory name into its listing.

Now do it again - same name. And again, and again, and again. Notice how Transmit each time adds the new directory to its listing.

Now leave Transmit be for the moment, and fire up a Terminal window, and navigate to the same directory and effect a listing with ls -al. What do you find?

Things compound when Transmit deals with remote file systems. Locate a remote server you have full access to, and upload a test file to it. Create the file locally and call it 'Clueless One'. Now upload it to your remote server.

What's the first thing you notice? Did Transmit do more than list the file name and its size? No. Did Transmit list the date and time of the file, or anything else normally listed? No.

Hit refresh with focus on 'their stuff' and see if it's all right now.

More Clues

Your left side and your right side should now be synchronized. It's time to play some more tricks with Transmit's inept programming crew.

Go into your local copy of 'Clueless One' with TextEdit. Launch TextEdit if necessary, and drag 'Clueless One' from the Finder onto TextEdit's dock icon. Do anything at all to alter the file size of 'Clueless One' and then save.

Note the new size of your local copy of 'Clueless One', and note that the listings for the two copies, local and remote, now differ.

Now upload your local copy to the remote server once more. When the upload is complete, Transmit should have the correct new size in its remote listing, but again lack the other details given for other files.

Now have Transmit refresh the remote file listing. What happened? Why did the file size go back to the previous, now incorrect, value? Ask the clueless Transmit programmers.

But we're not done yet - in fact, we have barely begun.

From Bad to Worse

You now have a local copy of the file 'Clueless One', the listing for which should be correct; but you also have a remote copy of the same file, and its listing should be all wrong. What makes this so tearful is that the file size listed was originally correct; and then you asked Transmit to refresh its listing, and it reverted - got it all wrong.

But that is not any fun compared with this: focus on the right pane ('their stuff') and click the listing for 'Clueless One' so the field becomes editable; now change the file name to 'Clueless Two' and hit Return.

What did Transmit do now? You bet! He's got both the old name and the new name listed! It can't get much more clueless than that! (Refresh the remote listing to remove the non-existent file.)

Tallying Up

What this all means is that the Transmit programming crew doesn't have a clue: they never thought of checking with the operating system to see if the directories you wanted to create were actually created or not; they made the enormous blunder of using the data from your file operation requests to list local files, instead of getting this information from the only reliable source there is, the operating system; they just assumed everything was going to be all right (and in this context it makes them look particularly dumb); they further revealed they know nothing about Unix - about how a file rename overwrites the destination if necessary; they again opted to not get their file information from the only reliable source, but to take it from (possibly erroneous) user input; and they revealed they are using a rather flawed cache system for remote file info - so flawed that when refreshing remote listings, correct data becomes incorrect.

Talkin' To Transmit

Transmit are aware of all the bugs mentioned on the previous pages. They have admitted to several of these, and even more. There exists a myriad of small cosmetic bugs and potential pitfalls in the program.

But while the Transmit crew readily acknowledge the accuracy of these bug reports, they do not give any indication of when their product will be corrected. As the program today carries a hefty price tag of US$25, any potential user aware of the bugs in the program should have confidence in the programming team's ability to fix the bugs, and the company's good intentions in getting these bug fixes out.

But Transmit say nothing more: they neither officially publish bug reports, nor give any indication whatsoever that the bugs will soon be fixed.

Which leaves the user in a very sorry predicament. It is simply not right to have to pay US$25 for a program as shoddily written as this; and yet people do need an FTP client, and Transmit is easily the best available for OS X.

Perhaps it is this knowledge that makes the Transmit crew complacent. Whatever: users of Transmit are being left high and dry, and potentially risk destroying important files.

Transmit 2.2

Transmit 2.2 was released on 19 December 2002. It was put together by someone named Dave. For what that matters. It is possible to know this because Dave incorrectly left his pbdevelopment.plist files all over the place.

<key>PBXProjectSourcePath</key>
<string>/Users/dave/Desktop/code/TransmitX/Transmit.pbproj</string>

Dave keeps his project on the desktop, where it's easy to find.


The release notes for Transmit 2.2 pay homage to only one of the known bugs:

Fixed a problem where you could create a duplicate local directory

Old habits die hard.


The Panic team at MWSF. Do these guys look old enough to write real world professional applications?

Still Terminally Clueless

 The Panic slogan really haunts:

'Shockingly Good Mac Software'

The only thing shocking about Panic software is that it is the most blundering such on the market ever.

Not even Microsoft programmers do such nimrod work.

The thought that this junk be foisted on the public as 'shockingly good' is detestable.

Ponder that image for a while. Note that it represents local files. Now ask yourself how any application - even a crappy Mac application - could be so dumb as to list seven files with the same name in the same directory.

That picture is worth far more than 1,000 words - it's worth at least $25.

About | Buy | Forum | Industry Watch | Learning Curve | Products | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.