Good idea, thanks! I'd prefer the shorter notation

self.respond(error || '…message…');

over

if(!error) error = '…message…';
self.respond(error);

In the long run we should make a messages dictionary to deduplicate magic string constants and separate i18n from code more.

PS: Github seems to not know the email address for your commits. That's not a problem for us, but you might want to double-check to optimize how you'll be represented in the commit log.

About the null check: if(storeStream === null) {
I'd prefer checking just truthiness (if(!storeStream) {), to tolerate custom filesystem implementations that might return other false-y values (e.g. undefined, false) on failure.

Good points, I've made improvements to reflect your concerns. They should both abide your style-guide and provide more consistent error checking.

var rs = self.fs.createReadStream(null, {fd: fd}); 
if(!rs || !(rs instanceof stream.Readable)) {

First, the !rs || part in the condition seems redundant:

[null, undefined, false, 0, NaN, ''].map((x) => (x instanceof Array))
// [ false, false, false, false, false, false ]

"Then":

  self._logIf(LOG.DEBUG, /* …message… */ ' (' + rs.constructor.name +
    ') which is not an instance of stream.Readable');

How do you know whether there will be a safe-to-access .constructor property in rs, even having a safe-to-access .name property?

The reason for just truthiness was not about coding style here, but about compatibility with custom filesystems. For me the improved compatibility would even warrant an exception from default style if required. Probably wouldn't hurt to add a reminder comment to the condition, e.g. "simplicity for sake of compatibility, cf. PR 132".

In that spirit, I wonder what the instanceof checks are for? They're always a red flag to me because they break easily where objects are imported from another execution context, e.g. sandboxes, e.g. iframes in browsers. It's the same reason as why there's Array.isArray: One sandbox's Array constructor !== another sandbox's Array constructor.

Even if there wasn't an issue across sandboxes, what would be bad about arbitrary objects that implement the readable stream interface? We can't afford to test that at runtime for each fs object we receive, but instanceof won't save us either; you can easily make an object that inherits from stream.Readable but implements the interface badly. That's why I prefer to accept any truthy value and trust the programmers that use ftpd to make their stream thingy behave correctly.