I had a backup. Really.

Unhappy surprise: PuTTY's PSFTP doesn't reflect batchfile errors in the exit code (+ patch)

Many of my customers use the PuTTY suite of secure remote access tools (mostly on Windows), and I've written about it here:

Tech Tip: Secure Linux/UNIX access with PuTTY and OpenSSH

PuTTY is great, but I made an unnerving discovery this weekend about PSFTP.

PSFTP is the SFTP client, which is sort of like FTP over SSH, and it allows for secure file transfers between the local machine and the remote server. Most of the time it's used interactively by a human, but it also supports a batch file option to run a bunch of commands all as a group, and it's often used to automate repeated file-transfer tasks (say, to upload a file to another server every night).

The unnerving discovery is that though PSFTP produces error messages during batchfile processing, the program's exit code is always "success" even if things went wrong. This means that the calling script has no real way of knowing that it didn't work.

Network or login errors do reflect an error exit status, but once it starts processing the batchfile, it's only going to exit with success status even if batchfile commands fail. Even a missing batchfile still causes a success exit code.

I suppose one way to deal with this is to parse the program's output looking for known error messages, but this is terribly unreliable, and is no substitute for PSFTP properly reflecting success or failure in the exit status: if anything goes wrong, the calling script should know about it so it can take some action (usually to notify somebody to have a look).

Note that the -be command-line parameter, which says to exit batch processing on error, doesn't impact the program's exit code.

This came as a total surprise, and in my application it mattered a lot because the calling script had to know if the file transferred or not. Needing this functionality, I created a patch against PSFTP.C that introduces a -batchfail command-line option that causes errors during batch file processing to exit with error status (if this option is not provided, there's no visible change in PSFTP's behavior).

This has been working well for me in my application, and I've submitted this patch to PuTTY's maintainers for consideration; I'm hoping they either accept it, or at least give some guidance on how I can make it better (and in the spirit of the rest of the code). The patch is against the current production release, v0.62.

psftp-batchfail-patch.txt

I'd sure love feedback among those who try this.

Tech Tip: Deploying Mitel IP Phones in a VLAN/DHCP Environment

I recently burned way too much time implementing a Mitel IP phone system for a customer, and it should not have been this difficult. Doing it the "easy" way - giving each phone a static IP on the same VLAN as the rest of the network - is just sloppy, especially considering that the phones are happy to play well on a more properly segregated network.

Our local support person was a great and helpful guy, but he simply didn't have this information, and my impression was that we were expected to go to Mitel Professional Services for network consulting (presumably for a fee).

Um, no.

So, I wrote this paper to help the next guy accomplish what we did, and maybe the general direction will be useful for other kinds of IP phones: feedback and related experiences are welcome.

Tech Tip: Deploying Mitel IP Phones in a VLAN/DHCP Environment

Alternate Data Streams and .NET - not supported

I have been working on a C# project on Windows where the use of Alternate Data Streams seemed appropriate, but found out to my dismay that the .NET framework simply doesn't support them.

Alternate Data Streams are a feature of NTFS that allow a file to contain, in addition to the primary data, additional data that's maintained on the side, and I believe it was conceived to support "resource forks" on the Mac. These are not well-known features, though Windows does use them for storing metadata about some kinds of files, such as an image thumbnail or noting the fact that a file was downloaded from the internet. I was going to use Alternate Data Streams for file metadata.

Alternate data streams are accessed with a stream name after the filename, separated by a colon, so that a base file might be C:\Data\Foo.txt, but a named stream might be C:\Data\foo.txt:mystream. A file can have multiple named streams, and streams are generally invisible unless asked for specifically by name.

The .NET framework's pathname parser allows a colon only after a drive letter, so the use of one as a stream name separator yields an exception, as does the same filename when prefixed with the \\?\ notation used to disable path parsing in Win32.

This bit of code shows what happens:

/* test.cs - C# code demonstrating failure of alternate data streams */

using System;
using System.IO;

namespace Unixwiz {

    public class Test {

        public static void Main(string [] args)
        {
            string filename = @"C:\Data\foo.txt:mystream";

            tryfile(           filename );
            tryfile( @"\\?\" + filename );
        }

        public static void tryfile(string name)
        {
            try
            {
                Console.WriteLine();
                Console.WriteLine("Trying to open file {0}", name);
                File.ReadAllText( name );
                Console.WriteLine("  OK!");
            }
            catch ( Exception ex )
            {
                Console.WriteLine("  Exception: {0}", ex.GetType());
                Console.WriteLine("  Message:   {0}", ex.Message);
            }
        }
    }
}

Running this shows the two kinds of exceptions generated:

C:> test.exe
Trying to open file C:\Data\foo.txt:mystream
  Exception: System.NotSupportedException
  Message:   The given path's format is not supported.

Trying to open file \\?\C:\Data\foo.txt:mystream
  Exception: System.ArgumentException
  Message:   Illegal characters in path.

I believe that one can get around this by the use of the Win32 CreateFile() function via PInvoke or the like, but decided not to go this route because I was likely to run into more surprises later when the cost of changing direction was much higher.

Useful resources:

• Accessing alternative data-streams of files on an NTFS volume — on CodeProject
• NTFS Alternate Data Streams - .NET — on StackOverflow