Filenames

One important question is "What filenames are supported by the FTP cluster?" Your user will have different expectations depending on the operating system they are used to. The good news is that the cluster supports any kind of filenames if you like it.

The standard scheme is UNIX-like.

Filenames must consist of normal letters, digits, dots, plus and minus signs. Upper and lowercase characters are different (and this is true for the other modes too). Leading dots in filenames are allowed (we talk about this later).

You can allow blanks.

If you give the -b option once you allow blanks in filenames. Your windows users will like you for that. If your users a working from within an FTP explorer plugin this is a must since new folders are created with the name "New Folder", watch the blank.

You can allow anything.

By specifying the -b option twice on the command line you enter the full (or don't care) filename mode. You do this perhaps you have decided for you that user education about filenames is simply a waste of time. Any characters are allowed in filenames, even the bad ones which are every UNIX system administrator's nightmare. Your users will like you even more for that.

Now for the cluster side of filenames. The fact that the cluster accepts any characters in filenames does not mean that these characters are used for filenames. In fact special characters (this are all characters beyond the UNIX-scheme above) are automatically %-encoded just as you know it from URLs. No shell (read shell as sh, ksh, bash etc., for csh I don't know if the % is special) special character is used in a real cluster or node filename. If a user decides to create a "New Folder" the cluster creates the directory "New%20Folder". As you see, your cluster scripts are safe.

Now let's consider you enabled full filename mode once and decided later to go back to the UNIX-scheme. What happens to all those files on your cluster with special characters in their names? They are still accessable, they can be read or deleted. Restricting characters means results in a "503 incompatible filename" if a user tries to create a file or directory with special characters.

Client software

This is also an important thing. There is a lot of client software around and most of them expect regular FTP servers speaking regular FTP protocol. But the cluster server supports only a subset, even of the basic FTP RFC 959. But more worse there might be clients that insist on speaking to a full FTP server.

So each client software should be first tested if it's working or not. Keep in mind that the cluster server does not support the "passive transfer mode" and it's also not planned for the next future. "Use PASV mode" is sometimes the keyword you have to look for. If possible uncheck the passive mode option, if not you can test if your software has an automatic active mode fallback.

Before you read on you should notice that my comment works does not mean that the software works completly. Read it as does not fail immediatly instead. Notice furthermore that this is also not a buyer's guide and no recommendation what you should buy and what not. And, as last comment, I didn't always test the latest versions. If you like you can send me your own experiences for publishing them.

UNIX console

The standard client ftp works, yafc also. By the way, I used yafc to copy my Linux kernel source tree into the cluster for a stress test. You have to get used to this program but then it's pretty good.

Midnight Commander mc works. It tries passive mode first and falls back to active mode. It seems that mc is not able to deal with the cluster's immutable i in the file permissions. It brings a number of error and ignores it then.

The FTP filesystem from lufs: works. This is perhaps the most interesting client (although it seems to have some problems in it's implementation) since it gives you a filesystem view of your FTP server.

X Windows

I was only able to check with the KDE file explorer (older version). It's not working. It can't read or open files from the server. Well, it reads but the files are empty. Suprisingly, the file explorer can write.

Windows

wsftp works, the windows file/Internet explorers FTP mode works. The FTP Neighborhood works, it also emulates FTP servers as network drive in your explorer and it does a good job.

Above I mentioned a stress test. What did I do?

• First I copied the my Linux kernel source tree wth yafc to the cluster server. This gave me a total of 12994 files. When you try something similiar keep in mind that FTP is not fast when it has to copy a lot of small files.

• Then I moved the files with store to my nodes. So far no error messages.

• When I copied the file tree back with wsftp I got only 12280 files. Why the difference? It took some time till I got the idea that there are filenames that differ only in lettercase which are therefore recognized as one file by the case-less windows. I found eight files with such names leaving me with a difference of six. I still do not know why six files were missing butI expect the reason to be also windows related.

• Copying the file tree from the cluster server to the local harddisk with lufs' ftpfs gave me 12994 files, showing me that the problem is not within the cluster.

One really nice thing of this test was that I saw the "FTP session closed" on my node servers after all files had been copied to the client. The cluster server was indeed capable of keeping the connection to it's nodes up as long as the user's client was connected to it.