I would surmise this descends from the bsd behaviour of letting you read() directories, whereas linux gives EISDIR. I'm not sure why that causes a hang rather than just giving back garbage; it may in fact be a bug in the sftp server.
I would further surmise that the sftp client is checking the type of the file before trying to read from it. I don't think we'd want Transport.read to do an extra roundtrip there in the general case but perhaps we should look before we leap when trying to read a bundle, by trying to stat the location.
Wade it could be useful if you could run a debugger or system call trace on the sftpd while this is hung and report what it's trying to do.
I would surmise this descends from the bsd behaviour of letting you read() directories, whereas linux gives EISDIR. I'm not sure why that causes a hang rather than just giving back garbage; it may in fact be a bug in the sftp server.
I would further surmise that the sftp client is checking the type of the file before trying to read from it. I don't think we'd want Transport.read to do an extra roundtrip there in the general case but perhaps we should look before we leap when trying to read a bundle, by trying to stat the location.
Wade it could be useful if you could run a debugger or system call trace on the sftpd while this is hung and report what it's trying to do.