Receives error 503 when making multiple renames immediately after each other

[martinvl]

When making two or more immediately (i.e. not waiting for callbacks) successive calls to .rename, the server responds with a 503. Use the code below to reproduce the error.

var Ftp = require('jsftp');

var client = new Ftp({
    // config goes here
});

client.put('foo', new Buffer('bar'), function () {});
client.put('bar', new Buffer('foo'), function () {});

client.rename('foo', 'foobar', function () {});
client.rename('bar', 'barfoo', function (err) {console.dir(err)});
// { [Error: 503 Need RNFR before RNTO] code: 503 }

Looking at the implementation of .rename, it looks to me like the RNTO call isn't queued before the callback from the RNFR call is received. Therefore it will be possible to smuggle other calls into the queue in between RNFR and RNTO, which probably is what causes the error.

Ideally .rename should be changed in some way such that it produces only a single item to be queued.

[sergi]

That would be a solution, but then every command would have to check for some lock mechanism from rename. Except for get and put, all other calls work in node.js style, that is, using callbacks. Most of the time it is not a problem to put sequential calls, but in the case of rename it is , since it uses 2 commands to accomplish the order, and indeed other calls can sneak between renames.

[fjakobs]

Was this issue fixed? I'm still seeing this error when moving multiple files in a C9 FTP project.

[sergi]

It is fixed because parallel calls are not possible in jsftp since 1.0. The same can be accomplished in a more 'node' way with callbacks or promises. What version are you on?

Also, I thought you were not using jsftp anymore in Cloud9 though and interfacing directly with an ftp child process?

[fjakobs]

We are still using jsftp but stuck on 0.5.5 because of some file listing issues. I fixed it now with this change https://github.com/ajaxorg/jsftp/commit/97d65da1c29f3bc9b1a2363431b87a7bc9520373

[sergi]

Ugh. It would be worth updating to 1.0 and test. Besides the one above, other reasons for upgrading:

• No more buffering, all streams. In the version you have there is buffering going on (I believe). This could slow down servers since big files are buffered in memory until they are transferred.
• File listings are transferred in A (text) mode, so you shouldn't have any more missing files because of strange formatting/truncation.
• Other bugs fixed along the way, and speed improvements, less dependencies, more unit tests, coverage, etc.

[danvass]

@sergi Is there a fix for this issue? I'm experiencing it with the latest version. @fjakobs Do you by chance know?