ssh2-sftp-client 9.0.1 → 9.0.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,108 +1,110 @@
1
- - [Overview](#org19c31e8)
2
- - [Version 9.x Changes](#orgc330d84)
3
- - [Installation](#org7c63f6a)
4
- - [Basic Usage](#orgb99a07c)
5
- - [Documentation](#org5550f37)
6
- - [Specifying Paths](#org2f0a3a6)
7
- - [Methods](#org8d230d5)
8
- - [new SftpClient(name) ===> SFTP client object](#orgc8b55d7)
9
- - [connect(config) ===> SFTP object](#org42512fb)
10
- - [list(path, filter) ==> Array[object]](#orgbe9e165)
11
- - [exists(path) ==> boolean](#org14dee5e)
12
- - [stat(path) ==> object](#orga0033c0)
13
- - [get(path, dst, options) ==> String|Stream|Buffer](#org02a3dc5)
14
- - [fastGet(remotePath, localPath, options) ===> string](#orge9f875d)
15
- - [put(src, remotePath, options) ==> string](#orgc7941ea)
16
- - [fastPut(localPath, remotePath, options) ==> string](#org8f8794d)
17
- - [append(input, remotePath, options) ==> string](#org82c75b5)
18
- - [mkdir(path, recursive) ==> string](#org42c5eeb)
19
- - [rmdir(path, recursive) ==> string](#orgd0aa59d)
20
- - [delete(path, noErrorOK) ==> string](#orgb496048)
21
- - [rename(fromPath, toPath) ==> string](#org1a2be8f)
22
- - [posixRename(fromPath, toPath) ==> string](#org571c0b9)
23
- - [chmod(path, mode) ==> string](#org02d64a4)
24
- - [realPath(path) ===> string](#org008d567)
25
- - [cwd() ==> string](#org7033d28)
26
- - [uploadDir(srcDir, dstDir, options) ==> string](#orgfa0102a)
27
- - [downloadDir(srcDir, dstDir, options) ==> string](#orgefe6fc6)
28
- - [createReadStream(remotePath, options)) ==> stream object](#org783e363)
29
- - [createWriteStream(remotePath, options) ==> stream object](#orgf45313d)
30
- - [rcopy(srcPath, dstPath) ==> string](#orga31c8c1)
31
- - [end() ==> boolean](#org4d02fde)
32
- - [Add and Remove Listeners](#orge5769d3)
33
- - [Platform Quirks & Warnings](#org3e6ddf9)
34
- - [Server Capabilities](#org61f0fe5)
35
- - [Promises, Events & Managing Exceptions](#orga7d6067)
36
- - [Adding Custom Handlers](#orgc08d427)
37
- - [Windows Based Servers](#org5439468)
38
- - [Don't Re-use SftpClient Objects](#orgae9129c)
39
- - [FAQ](#org3761660)
40
- - [Remote server drops connections with only an end event](#org1e669d1)
41
- - [How can I pass writable stream as dst for get method?](#org71d5bab)
42
- - [How can I upload files without having to specify a password?](#orgaafc964)
43
- - [How can I connect through a Socks Proxy](#orgebf85e2)
44
- - [Timeout while waiting for handshake or handshake errors](#org528d9ea)
45
- - [How can I limit upload/download speed](#org3b6ff20)
46
- - [Connection hangs or fails for larger files](#orgb5e285f)
47
- - [Examples](#org18ce0c2)
48
- - [Troubleshooting](#orgf4b6c80)
49
- - [Common Errors](#orga419582)
50
- - [Not returning the promise in a `then()` block](#orgd5f3557)
51
- - [Mixing Promise Chains and Async/Await](#org557d1c5)
52
- - [Try/catch and Error Handlers](#org2bf9a3a)
53
- - [Server Differences](#org89795d7)
54
- - [Avoid Concurrent Operations](#orgbec08b0)
55
- - [Debugging Support](#org124cfc9)
56
- - [Logging Issues](#org5f3c941)
57
- - [Pull Requests](#org6e82efc)
58
- - [Contributors](#org680b5c2)
59
-
60
-
61
-
62
- <a id="org19c31e8"></a>
63
-
64
- # Overview
1
+ - [Overview](#sec-1)
2
+ - [Version 9.x Changes](#sec-1-1)
3
+ - [Installation](#sec-2)
4
+ - [Basic Usage](#sec-3)
5
+ - [Documentation](#sec-4)
6
+ - [Specifying Paths](#sec-4-1)
7
+ - [Methods](#sec-4-2)
8
+ - [new SftpClient(name) ===> SFTP client object](#sec-4-2-1)
9
+ - [connect(config) ===> SFTP object](#sec-4-2-2)
10
+ - [list(path, filter) ==> Array[object]](#sec-4-2-3)
11
+ - [exists(path) ==> boolean](#sec-4-2-4)
12
+ - [stat(path) ==> object](#sec-4-2-5)
13
+ - [get(path, dst, options) ==> String|Stream|Buffer](#sec-4-2-6)
14
+ - [fastGet(remotePath, localPath, options) ===> string](#sec-4-2-7)
15
+ - [put(src, remotePath, options) ==> string](#sec-4-2-8)
16
+ - [fastPut(localPath, remotePath, options) ==> string](#sec-4-2-9)
17
+ - [append(input, remotePath, options) ==> string](#sec-4-2-10)
18
+ - [mkdir(path, recursive) ==> string](#sec-4-2-11)
19
+ - [rmdir(path, recursive) ==> string](#sec-4-2-12)
20
+ - [delete(path, noErrorOK) ==> string](#sec-4-2-13)
21
+ - [rename(fromPath, toPath) ==> string](#sec-4-2-14)
22
+ - [posixRename(fromPath, toPath) ==> string](#sec-4-2-15)
23
+ - [chmod(path, mode) ==> string](#sec-4-2-16)
24
+ - [realPath(path) ===> string](#sec-4-2-17)
25
+ - [cwd() ==> string](#sec-4-2-18)
26
+ - [uploadDir(srcDir, dstDir, options) ==> string](#sec-4-2-19)
27
+ - [downloadDir(srcDir, dstDir, options) ==> string](#sec-4-2-20)
28
+ - [createReadStream(remotePath, options)) ==> stream object](#sec-4-2-21)
29
+ - [createWriteStream(remotePath, options) ==> stream object](#sec-4-2-22)
30
+ - [rcopy(srcPath, dstPath) ==> string](#sec-4-2-23)
31
+ - [end() ==> boolean](#sec-4-2-24)
32
+ - [Add and Remove Listeners](#sec-4-2-25)
33
+ - [Platform Quirks & Warnings](#sec-5)
34
+ - [Server Capabilities](#sec-5-1)
35
+ - [Issues with `fastPut()` and `fastGet()` Methods](#sec-5-2)
36
+ - [Promises, Events & Managing Exceptions](#sec-5-3)
37
+ - [Adding Custom Handlers](#sec-5-3-1)
38
+ - [Windows Based Servers](#sec-5-4)
39
+ - [Don't Re-use SftpClient Objects](#sec-5-5)
40
+ - [FAQ](#sec-6)
41
+ - [Remote server drops connections with only an end event](#sec-6-1)
42
+ - [How can I pass writeable stream as dst for get method?](#sec-6-2)
43
+ - [How can I upload files without having to specify a password?](#sec-6-3)
44
+ - [How can I connect through a Socks Proxy](#sec-6-4)
45
+ - [Timeout while waiting for handshake or handshake errors](#sec-6-5)
46
+ - [How can I limit upload/download speed](#sec-6-6)
47
+ - [Connection hangs or fails for larger files](#sec-6-7)
48
+ - [Examples](#sec-7)
49
+ - [Troubleshooting](#sec-8)
50
+ - [Common Errors](#sec-8-1)
51
+ - [Not returning the promise in a `then()` block](#sec-8-1-1)
52
+ - [Mixing Promise Chains and Async/Await](#sec-8-1-2)
53
+ - [Try/catch and Error Handlers](#sec-8-1-3)
54
+ - [Server Differences](#sec-8-1-4)
55
+ - [Avoid Concurrent Operations](#sec-8-1-5)
56
+ - [Debugging Support](#sec-8-2)
57
+ - [Logging Issues](#sec-9)
58
+ - [Pull Requests](#sec-10)
59
+ - [Contributors](#sec-11)
60
+
61
+
62
+ # Overview<a id="sec-1"></a>
65
63
 
66
64
  an SFTP client for node.js, a wrapper around [SSH2](https://github.com/mscdex/ssh2) which provides a high level convenience abstraction as well as a Promise based API.
67
65
 
68
66
  Documentation on the methods and available options in the underlying modules can be found on the [SSH2](https://github.com/mscdex/ssh2) project pages.
69
67
 
70
- Current stable release is **v9.0.1**.
68
+ Current stable release is **v9.0.4**.
71
69
 
72
- Code has been tested against Node versions 14.19.1, 16.15.0 and 18.1.0
70
+ Code has been tested against Node versions 14.20.0, 16.17.2 and 18.8.0
73
71
 
74
72
  Node versions < 14.x are not supported.
75
73
 
74
+ ## Version 9.x Changes<a id="sec-1-1"></a>
76
75
 
77
- <a id="orgc330d84"></a>
78
-
79
- ## Version 9.x Changes
80
-
76
+ - Fix bug in `connect()` method when private key data was corrupted. The method was not handling errors fro corrupted ssh private keys and would hang indefinitely without reporting any error. Now reports that it was unable to parse the private key.
77
+ - Fix bug in `end()` method where it was possible for the module to attempt calling the underlying ssh2 `end()` method when ssh2 has not been initialised. This could lead to undefined reference errors.
78
+ - Fix bug in `get()` method where supplied destination streams were not close, creating a possible resource leak. If the remote file did not exist, the method would return an error, but failed to close any passed in stream supplied as the destination for the data in the `get()` call.
79
+ - Change the default end and close handlers not to throw error or reject promises. Previously, an end or close event would cause an error to be raised or a promise to be rejected if the event was deemed to be *unexpected*. However, classification of events as being unexpected was unreliable and didn't add much real value. Both these handlers will now invalidate the SFTP connection object and log that the event fired and nothing else.
80
+ - Changed when event handled flags are reset. Now they are reset after a new set of temporary listeners are added.
81
+ - Don't throw an error when calling end() if there is no active SFTP connection. It does no harm to call end() when there is no connection, so no need to raise an error.
82
+ - Use nullish coalescing when setting retry parameters instead of or'ing with defaults. Allows setting values to 0.
81
83
  - **Breaking Change**: This version uses syntax not supported in node versions prior to v14. Therefore, node versions less than v14 will not work.
82
84
  - **Breaking Change**: This `list()` method no longer accepts a regular expression for filtering the entries to be returned. You can now specify a filter function instead. The function is called for each item in the list of items to be returned, passing in the item object as its only argument. Essentially, this is just a call to `Array.filter()`, so the filter function should behave in the same way i.e. return true for items to be retained and false for those to be dropped.
83
85
  - **Breaking Change**: The ability to set `autoClose` on read and write streams and the ability to set `end` on `pipe` operations has been removed. These options caused confusion for users and were too easy to get wrong, plus it made the methods overly complicated. For those use-cases where you want to control streams at a low level, two new methods have been added, `createReadStream()` and `createWriteStream()`. However, it should be noted that client code is 100% responsible for managing streams obtained using these methods. Use at your own risk!
84
- - **Breaking Change**: The 3rd argument to `uploadDir()` and `downloadDir()` methods has been change. Previously, the argument was a filter function used to select which directories and files to be transferred. The 3rd argument is now an options object with two supported properties, `filter` and `useFastput` (for `uploadDir()`) or `useFastget` (for `downloadDir()`). If `useFastput` is true, the `fastPut()` method will be pused to upload files. If `false` or missing, the slower, but better supported, `put()` method will be used. Likewise, the `useFastget` options can be set to `true` to use the `fastGet()` method for donwloading files, otherwise the slower, but more reliable, `get()` method will be used.
85
- - The `uploadDir()` and `downloadDir()` methods now use asynchrounous processes to upload/download files. This should result in improved performance for these two methods.
86
- - New Methods: Two new methods, `createWriteStream()` and `createReadStream()` have been added. These methods will return a stream object connected to a remote file on the `sftp` server. Client code is responsible for managing these stream objects. This includes adding any necessary event listeners and disposing of the objects once finished with them.
87
- - Refactoring of Listeners: The library manages temporary listeners in order to provide a way to catch events and processes them inside a `Promise` context. Previously, every method added its own set of temporary listeners. However, this could result in multiple sets of listeners being added, especially for methods which call other methods as part of their processing e.g. `rmdir(),` `uploadDir()` and `dowqnloadDir()`. To avoid this, *internal only* versions of each method have been created. These internal methods use an *underscore* `_` prefix. Client code should not use these methods directly.
86
+ - **Breaking Change**: The 3rd argument to `uploadDir()` and `downloadDir()` methods has been change. Previously, the argument was a filter function used to select which directories and files to be transferred. The 3rd argument is now an options object with two supported properties, `filter` and `useFastput` (for `uploadDir()`) or `useFastget` (for `downloadDir()`). If `useFastput` is true, the `fastPut()` method will be used to upload files. If `false` or missing, the slower, but better supported, `put()` method will be used. Likewise, the `useFastget` options can be set to `true` to use the `fastGet()` method for downloading files, otherwise the slower, but more reliable, `get()` method will be used.
87
+ - The `uploadDir()` and `downloadDir()` methods now use asynchronous processes to upload/download files. This should result in improved performance for these two methods.
88
+ - New Methods: Two new methods, `createWriteStream()` and `createReadStream()` have been added. These methods will return a stream object connected to a remote file on the `SFTP` server. Client code is responsible for managing these stream objects. This includes adding any necessary event listeners and disposing of the objects once finished with them.
89
+ - Re-factoring of Listeners: The library manages temporary listeners in order to provide a way to catch events and processes them inside a `Promise` context. Previously, every method added its own set of temporary listeners. However, this could result in multiple sets of listeners being added, especially for methods which call other methods as part of their processing e.g. `rmdir(),` `uploadDir()` and `dowqnloadDir()`. To avoid this, *internal only* versions of each method have been created. These internal methods use an *underscore* `_` prefix. Client code should not use these methods directly.
88
90
  - New method: Added `rcopy()` method to perform a remote copy of a file on the remote SFTP server.
89
91
  - Bumped ssh2 version to 1.11.0
90
92
 
93
+ # Installation<a id="sec-2"></a>
91
94
 
92
- <a id="org7c63f6a"></a>
95
+ ```shell
93
96
 
94
- # Installation
97
+ npm
95
98
 
96
- ```shell
97
99
  npm install ssh2-sftp-client
98
100
  ```
99
101
 
102
+ # Basic Usage<a id="sec-3"></a>
100
103
 
101
- <a id="orgb99a07c"></a>
104
+ ```javascript
102
105
 
103
- # Basic Usage
106
+ let
104
107
 
105
- ```javascript
106
108
  let Client = require('ssh2-sftp-client');
107
109
  let sftp = new Client();
108
110
 
@@ -120,19 +122,13 @@ sftp.connect({
120
122
  });
121
123
  ```
122
124
 
123
-
124
- <a id="org5550f37"></a>
125
-
126
- # Documentation
125
+ # Documentation<a id="sec-4"></a>
127
126
 
128
127
  The connection options are the same as those offered by the underlying SSH2 module. For full details, please see [SSH2 client methods](https://github.com/mscdex/ssh2#user-content-client-methods)
129
128
 
130
129
  All the methods will return a Promise, except for `on()` and `removeListener()`, which are typically only used in special use cases.
131
130
 
132
-
133
- <a id="org2f0a3a6"></a>
134
-
135
- ## Specifying Paths
131
+ ## Specifying Paths<a id="sec-4-1"></a>
136
132
 
137
133
  The convention with both FTP and SFTP is that paths are specified using a 'nix' style i.e. use `/` as the path separator. This means that even if your SFTP server is running on a win32 platform, you should use `/` instead of `\` as the path separator. For example, for a win32 path of `C:\Users\fred` you would actually use `/C:/Users/fred`. If your win32 server does not support the 'nix' path convention, you can try setting the `remotePathSep` property of the `SftpClient` object to the path separator of your remote server. This **might** work, but has not been tested. Please let me know if you need to do this and provide details of the SFTP server so that I can try to create an appropriate environment and adjust things as necessary. At this point, I'm not aware of any win32 based SFTP servers which do not support the 'nix' path convention.
138
134
 
@@ -142,35 +138,38 @@ It is important to recognise that the current remote directory may not always be
142
138
 
143
139
  There is a small performance hit for using `./` and `../` as the module must query the remote server to determine what the root path is and derive the absolute path. Using absolute paths are therefore more efficient and likely more robust.
144
140
 
145
- When specifying file paths, ensure to include a full path i.e. include the remote filename. Don't expect the module to append the local file name to the path you provide. For example, the following will not work
141
+ When specifying file paths, ensure to include a full path i.e. include the remote file name. Don't expect the module to append the local file name to the path you provide. For example, the following will not work
146
142
 
147
143
  ```javascript
144
+
145
+
146
+
148
147
  client.put('/home/fred/test.txt', '/remote/dir');
149
148
  ```
150
149
 
151
- will not result in the file `test.txt` being copied to `/remote/dir/test.txt`. You need to specify the target filename as well e.g.
150
+ will not result in the file `test.txt` being copied to `/remote/dir/test.txt`. You need to specify the target file name as well e.g.
152
151
 
153
152
  ```javascript
153
+
154
+
155
+
154
156
  client.put('/home/fred/test.txt', '/remote/dir/test.txt');
155
157
  ```
156
158
 
157
159
  Note that the remote file name does not have to be the same as the local file name. The following works fine;
158
160
 
159
161
  ```javascript
160
- client.put('/home/fred/test.txt', '/remote/dir/test-copy.txt');
161
- ```
162
-
163
- This will copy the local file `test.txt` to the remote file `test-copy.txt` in the directory `/remote/dir`.
164
162
 
165
163
 
166
- <a id="org8d230d5"></a>
167
164
 
168
- ## Methods
165
+ client.put('/home/fred/test.txt', '/remote/dir/test-copy.txt');
166
+ ```
169
167
 
168
+ This will copy the local file `test.txt` to the remote file `test-copy.txt` in the directory `/remote/dir`.
170
169
 
171
- <a id="orgc8b55d7"></a>
170
+ ## Methods<a id="sec-4-2"></a>
172
171
 
173
- ### new SftpClient(name) ===> SFTP client object
172
+ ### new SftpClient(name) ===> SFTP client object<a id="sec-4-2-1"></a>
174
173
 
175
174
  Constructor to create a new `ssh2-sftp-client` object. An optional `name` string can be provided, which will be used in error messages to help identify which client has thrown the error.
176
175
 
@@ -181,6 +180,9 @@ Constructor to create a new `ssh2-sftp-client` object. An optional `name` string
181
180
  2. Example Use
182
181
 
183
182
  ```javascript
183
+
184
+ 'use
185
+
184
186
  'use strict';
185
187
 
186
188
  const Client = require('ssh2-sftp-client');
@@ -206,10 +208,7 @@ Constructor to create a new `ssh2-sftp-client` object. An optional `name` string
206
208
  });
207
209
  ```
208
210
 
209
-
210
- <a id="org42512fb"></a>
211
-
212
- ### connect(config) ===> SFTP object
211
+ ### connect(config) ===> SFTP object<a id="sec-4-2-2"></a>
213
212
 
214
213
  Connect to an sftp server. Full documentation for connection options is available [here](https://github.com/mscdex/ssh2#user-content-client-methods)
215
214
 
@@ -220,6 +219,9 @@ Connect to an sftp server. Full documentation for connection options is availabl
220
219
  The `retries`, `retry_factor` and `retry_minTimeout` options are not part of the SSH2 module. These are part of the configuration for the [retry](https://www.npmjs.com/package/retry) package and what is used to enable retrying of sftp connection attempts. See the documentation for that package for an explanation of these values.
221
220
 
222
221
  ```javascript
222
+
223
+ //
224
+
223
225
  // common options
224
226
 
225
227
  let commonOpts {
@@ -264,6 +266,10 @@ Connect to an sftp server. Full documentation for connection options is availabl
264
266
  2. Example Use
265
267
 
266
268
  ```javascript
269
+
270
+ sftp.connect({
271
+
272
+
267
273
  sftp.connect({
268
274
  host: example.com,
269
275
  port: 22,
@@ -272,10 +278,7 @@ Connect to an sftp server. Full documentation for connection options is availabl
272
278
  });
273
279
  ```
274
280
 
275
-
276
- <a id="orgbe9e165"></a>
277
-
278
- ### list(path, filter) ==> Array[object]
281
+ ### list(path, filter) ==> Array[object]<a id="sec-4-2-3"></a>
279
282
 
280
283
  Retrieves a directory listing. This method returns a Promise, which once realised, returns an array of objects representing items in the remote directory.
281
284
 
@@ -285,6 +288,9 @@ Retrieves a directory listing. This method returns a Promise, which once realise
285
288
  1. Example Use
286
289
 
287
290
  ```javascript
291
+
292
+ const
293
+
288
294
  const Client = require('ssh2-sftp-client');
289
295
 
290
296
  const config = {
@@ -315,44 +321,24 @@ Retrieves a directory listing. This method returns a Promise, which once realise
315
321
 
316
322
  The objects in the array returned by `list()` have the following properties;
317
323
 
318
- ```javascript
319
- {
320
- type: // file type(-, d, l)
321
- name: // file name
322
- size: // file size
323
- modifyTime: // file timestamp of modified time
324
- accessTime: // file timestamp of access time
325
- rights: {
326
- user:
327
- group:
328
- other:
329
- },
330
- owner: // user ID
331
- group: // group ID
332
- longname: // like ls -l line
333
- }
334
- ```
335
-
336
- 3. Pattern Filter
337
-
338
- The filter options can be a regular expression (most powerful option) or a simple *glob*-like string where \* will match any number of characters, e.g.
339
-
340
- foo* => foo, foobar, foobaz
341
- *bar => bar, foobar, tabbar
342
- *oo* => foo, foobar, look, book
324
+ ```nillangnilswitchesnilflags
325
+ nilbody
326
+ #+END_SRC
343
327
 
344
- The *glob*-style matching is very simple. In most cases, you are best off using a real regular expression which will allow you to do more powerful matching and anchor matches to the beginning/end of the string etc.
345
-
346
-
347
- <a id="org14dee5e"></a>
328
+ ***
329
+ nilbody
330
+ ```
348
331
 
349
- ### exists(path) ==> boolean
332
+ ### exists(path) ==> boolean<a id="sec-4-2-4"></a>
350
333
 
351
334
  Tests to see if remote file or directory exists. Returns type of remote object if it exists or false if it does not.
352
335
 
353
336
  1. Example Use
354
337
 
355
338
  ```javascript
339
+
340
+ const
341
+
356
342
  const Client = require('ssh2-sftp-client');
357
343
 
358
344
  const config = {
@@ -379,10 +365,7 @@ Tests to see if remote file or directory exists. Returns type of remote object i
379
365
  });
380
366
  ```
381
367
 
382
-
383
- <a id="orga0033c0"></a>
384
-
385
- ### stat(path) ==> object
368
+ ### stat(path) ==> object<a id="sec-4-2-5"></a>
386
369
 
387
370
  Returns the attributes associated with the object pointed to by `path`.
388
371
 
@@ -393,6 +376,9 @@ Returns the attributes associated with the object pointed to by `path`.
393
376
  The `stat()` method returns an object with the following properties;
394
377
 
395
378
  ```javascript
379
+
380
+ let
381
+
396
382
  let stats = {
397
383
  mode: 33279, // integer representing type and permissions
398
384
  uid: 1000, // user ID
@@ -413,6 +399,9 @@ Returns the attributes associated with the object pointed to by `path`.
413
399
  2. Example Use
414
400
 
415
401
  ```javascript
402
+
403
+ let
404
+
416
405
  let client = new Client();
417
406
 
418
407
  client.connect(config)
@@ -430,10 +419,7 @@ Returns the attributes associated with the object pointed to by `path`.
430
419
  });
431
420
  ```
432
421
 
433
-
434
- <a id="org02a3dc5"></a>
435
-
436
- ### get(path, dst, options) ==> String|Stream|Buffer
422
+ ### get(path, dst, options) ==> String|Stream|Buffer<a id="sec-4-2-6"></a>
437
423
 
438
424
  Retrieve a file from a remote SFTP server. The `dst` argument defines the destination and can be either a string, a stream object or undefined. If it is a string, it is interpreted as the path to a location on the local file system (path should include the file name). If it is a stream object, the remote data is passed to it via a call to pipe(). If `dst` is undefined, the method will put the data into a buffer and return that buffer when the Promise is resolved. If `dst` is defined, it is returned when the Promise is resolved.
439
425
 
@@ -448,6 +434,9 @@ In general, if you're going to pass in a string as the destination, you are bett
448
434
  The `options` argument can be used to pass options to the underlying streams and pipe call used by this method. The argument is an object with three possible properties, `readStreamOptions`, `writeStreamOptions` and `pipeOptions`. The values for each of these properties should be an object containing the required options. For example, possible read stream and pipe options could be defined as
449
435
 
450
436
  ```javascript
437
+
438
+ let
439
+
451
440
  let options = {
452
441
  readStreamOptions: {
453
442
  flags: 'r',
@@ -467,6 +456,9 @@ In general, if you're going to pass in a string as the destination, you are bett
467
456
  2. Example Use
468
457
 
469
458
  ```javascript
459
+
460
+ let
461
+
470
462
  let client = new Client();
471
463
 
472
464
  let remotePath = '/remote/server/path/file.txt';
@@ -486,10 +478,7 @@ In general, if you're going to pass in a string as the destination, you are bett
486
478
 
487
479
  - **Tip:** See examples file in the Git repository for more examples. You can pass any writeable stream in as the destination. For example, if you pass in `zlib.createGunzip()` writeable stream, you can both download and decompress a gzip file 'on the fly'.
488
480
 
489
-
490
- <a id="orge9f875d"></a>
491
-
492
- ### fastGet(remotePath, localPath, options) ===> string
481
+ ### fastGet(remotePath, localPath, options) ===> string<a id="sec-4-2-7"></a>
493
482
 
494
483
  Downloads a file at remotePath to localPath using parallel reads for faster throughput. This is the simplest method if you just want to download a file.
495
484
 
@@ -499,13 +488,12 @@ Downloads a file at remotePath to localPath using parallel reads for faster thro
499
488
 
500
489
  1. Options
501
490
 
502
- ```javascript
503
- {
504
- concurrency: 64, // integer. Number of concurrent reads to use
505
- chunkSize: 32768, // integer. Size of each read in bytes
506
- step: function(total_transferred, chunk, total) // callback called each time a
507
- // chunk is transferred
508
- }
491
+ ```nillangnilswitchesnilflags
492
+ nilbody
493
+ #+END_SRC
494
+
495
+ -
496
+ nilbody
509
497
  ```
510
498
 
511
499
  - **Warning:** Some servers do not respond correctly to requests to alter chunk size. This can result in lost or corrupted data.
@@ -513,6 +501,9 @@ Downloads a file at remotePath to localPath using parallel reads for faster thro
513
501
  2. Sample Use
514
502
 
515
503
  ```javascript
504
+
505
+ let
506
+
516
507
  let client = new Client();
517
508
  let remotePath = '/server/path/file.txt';
518
509
  let localPath = '/local/path/file.txt';
@@ -529,10 +520,7 @@ Downloads a file at remotePath to localPath using parallel reads for faster thro
529
520
  });
530
521
  ```
531
522
 
532
-
533
- <a id="orgc7941ea"></a>
534
-
535
- ### put(src, remotePath, options) ==> string
523
+ ### put(src, remotePath, options) ==> string<a id="sec-4-2-8"></a>
536
524
 
537
525
  Upload data from local system to remote server. If the `src` argument is a string, it is interpreted as a local file path to be used for the data to transfer. If the `src` argument is a buffer, the contents of the buffer are copied to the remote file and if it is a readable stream, the contents of that stream are piped to the `remotePath` on the server.
538
526
 
@@ -544,13 +532,12 @@ Upload data from local system to remote server. If the `src` argument is a strin
544
532
 
545
533
  The options object supports three properties, `readStreamOptions`, `writeStreamOptions` and `pipeOptions`. The value for each property should be an object with options as properties and their associated values representing the option value. For example, you might use the following to set `writeStream` options.
546
534
 
547
- ```javascript
548
- {
549
- writeStreamOptions: {
550
- flags: 'w', // w - write and a - append
551
- encoding: null, // use null for binary files
552
- mode: 0o666, // mode to use for created file (rwx)
553
- }}
535
+ ```nillangnilswitchesnilflags
536
+ nilbody
537
+ #+END_SRC
538
+
539
+ The
540
+ nilbody
554
541
  ```
555
542
 
556
543
  The most common options to use are mode and encoding. The values shown above are the defaults. You do not have to set encoding to utf-8 for text files, null is fine for all file types. However, using utf-8 encoding for binary files will often result in data corruption.
@@ -560,6 +547,9 @@ Upload data from local system to remote server. If the `src` argument is a strin
560
547
  2. Example Use
561
548
 
562
549
  ```javascript
550
+
551
+ let
552
+
563
553
  let client = new Client();
564
554
 
565
555
  let data = fs.createReadStream('/path/to/local/file.txt');
@@ -579,10 +569,7 @@ Upload data from local system to remote server. If the `src` argument is a strin
579
569
 
580
570
  - **Tip:** If the src argument is a path string, consider just using `fastPut()`.
581
571
 
582
-
583
- <a id="org8f8794d"></a>
584
-
585
- ### fastPut(localPath, remotePath, options) ==> string
572
+ ### fastPut(localPath, remotePath, options) ==> string<a id="sec-4-2-9"></a>
586
573
 
587
574
  Uploads the data in file at `localPath` to a new file on remote server at `remotePath` using concurrency. The options object allows tweaking of the fast put process.
588
575
 
@@ -592,14 +579,12 @@ Uploads the data in file at `localPath` to a new file on remote server at `remot
592
579
 
593
580
  1. Options
594
581
 
595
- ```javascript
596
- {
597
- concurrency: 64, // integer. Number of concurrent reads
598
- chunkSize: 32768, // integer. Size of each read in bytes
599
- mode: 0o755, // mixed. Integer or string representing the file mode to set
600
- step: function(total_transferred, chunk, total) // function. Called every time
601
- // a part of a file was transferred
602
- }
582
+ ```nillangnilswitchesnilflags
583
+ nilbody
584
+ #+END_SRC
585
+
586
+ -
587
+ nilbody
603
588
  ```
604
589
 
605
590
  - **Warning:** There have been reports that some SFTP servers will not honour requests for non-default chunk sizes. This can result in data loss or corruption.
@@ -607,6 +592,9 @@ Uploads the data in file at `localPath` to a new file on remote server at `remot
607
592
  2. Example Use
608
593
 
609
594
  ```javascript
595
+
596
+ let
597
+
610
598
  let localFile = '/path/to/file.txt';
611
599
  let remoteFile = '/path/to/remote/file.txt';
612
600
  let client = new Client();
@@ -623,10 +611,7 @@ Uploads the data in file at `localPath` to a new file on remote server at `remot
623
611
  });
624
612
  ```
625
613
 
626
-
627
- <a id="org82c75b5"></a>
628
-
629
- ### append(input, remotePath, options) ==> string
614
+ ### append(input, remotePath, options) ==> string<a id="sec-4-2-10"></a>
630
615
 
631
616
  Append the `input` data to an existing remote file. There is no integrity checking performed apart from normal writeStream checks. This function simply opens a writeStream on the remote file in append mode and writes the data passed in to the file.
632
617
 
@@ -638,13 +623,12 @@ Append the `input` data to an existing remote file. There is no integrity checki
638
623
 
639
624
  The following options are supported;
640
625
 
641
- ```javascript
642
- {
643
- flags: 'a', // w - write and a - append
644
- encoding: null, // use null for binary files
645
- mode: 0o666, // mode to use for created file (rwx)
646
- autoClose: true // automatically close the write stream when finished
647
- }
626
+ ```nillangnilswitchesnilflags
627
+ nilbody
628
+ #+END_SRC
629
+
630
+ The
631
+ nilbody
648
632
  ```
649
633
 
650
634
  The most common options to use are mode and encoding. The values shown above are the defaults. You do not have to set encoding to utf-8 for text files, null is fine for all file types. Generally, I would not attempt to append binary files.
@@ -652,6 +636,9 @@ Append the `input` data to an existing remote file. There is no integrity checki
652
636
  2. Example Use
653
637
 
654
638
  ```javascript
639
+
640
+ let
641
+
655
642
  let remotePath = '/path/to/remote/file.txt';
656
643
  let client = new Client();
657
644
 
@@ -667,10 +654,7 @@ Append the `input` data to an existing remote file. There is no integrity checki
667
654
  });
668
655
  ```
669
656
 
670
-
671
- <a id="org42c5eeb"></a>
672
-
673
- ### mkdir(path, recursive) ==> string
657
+ ### mkdir(path, recursive) ==> string<a id="sec-4-2-11"></a>
674
658
 
675
659
  Create a new directory. If the recursive flag is set to true, the method will create any directories in the path which do not already exist. Recursive flag defaults to false.
676
660
 
@@ -680,6 +664,9 @@ Create a new directory. If the recursive flag is set to true, the method will cr
680
664
  1. Example Use
681
665
 
682
666
  ```javascript
667
+
668
+ let
669
+
683
670
  let remoteDir = '/path/to/new/dir';
684
671
  let client = new Client();
685
672
 
@@ -695,10 +682,7 @@ Create a new directory. If the recursive flag is set to true, the method will cr
695
682
  });
696
683
  ```
697
684
 
698
-
699
- <a id="orgd0aa59d"></a>
700
-
701
- ### rmdir(path, recursive) ==> string
685
+ ### rmdir(path, recursive) ==> string<a id="sec-4-2-12"></a>
702
686
 
703
687
  Remove a directory. If removing a directory and recursive flag is set to `true`, the specified directory and all sub-directories and files will be deleted. If set to false and the directory has sub-directories or files, the action will fail.
704
688
 
@@ -710,6 +694,9 @@ Remove a directory. If removing a directory and recursive flag is set to `true`,
710
694
  1. Example Use
711
695
 
712
696
  ```javascript
697
+
698
+ let
699
+
713
700
  let remoteDir = '/path/to/remote/dir';
714
701
  let client = new Client();
715
702
 
@@ -725,10 +712,7 @@ Remove a directory. If removing a directory and recursive flag is set to `true`,
725
712
  });
726
713
  ```
727
714
 
728
-
729
- <a id="orgb496048"></a>
730
-
731
- ### delete(path, noErrorOK) ==> string
715
+ ### delete(path, noErrorOK) ==> string<a id="sec-4-2-13"></a>
732
716
 
733
717
  Delete a file on the remote server.
734
718
 
@@ -739,6 +723,9 @@ Delete a file on the remote server.
739
723
  1. Example Use
740
724
 
741
725
  ```javascript
726
+
727
+ let
728
+
742
729
  let remoteFile = '/path/to/remote/file.txt';
743
730
  let client = new Client();
744
731
 
@@ -754,10 +741,7 @@ Delete a file on the remote server.
754
741
  });
755
742
  ```
756
743
 
757
-
758
- <a id="org1a2be8f"></a>
759
-
760
- ### rename(fromPath, toPath) ==> string
744
+ ### rename(fromPath, toPath) ==> string<a id="sec-4-2-14"></a>
761
745
 
762
746
  Rename a file or directory from `fromPath` to `toPath`. You must have the necessary permissions to modify the remote file.
763
747
 
@@ -767,6 +751,9 @@ Rename a file or directory from `fromPath` to `toPath`. You must have the necess
767
751
  1. Example Use
768
752
 
769
753
  ```javascript
754
+
755
+ let
756
+
770
757
  let from = '/remote/path/to/old.txt';
771
758
  let to = '/remote/path/to/new.txt';
772
759
  let client = new Client();
@@ -783,17 +770,17 @@ Rename a file or directory from `fromPath` to `toPath`. You must have the necess
783
770
  });
784
771
  ```
785
772
 
773
+ ### posixRename(fromPath, toPath) ==> string<a id="sec-4-2-15"></a>
786
774
 
787
- <a id="org571c0b9"></a>
788
-
789
- ### posixRename(fromPath, toPath) ==> string
790
-
791
- This method uses the openssh POSIX rename extension introduced in OpenSSH 4.8. The advantage of this version of rename over standard SFTP rename is that it is an atomic operation and will allow renaming a resource where the destination name exists. The POSIX rename will also work on some filesystems which do not support standard SFTP rename because they don't support the system hardlink() call. The POSIX rename extension is available on all openSSH servers from 4.8 and some other implementations. This is an extension to the standard SFTP protocol and therefore is not supported on all sSFTP servers.
775
+ This method uses the openssh POSIX rename extension introduced in OpenSSH 4.8. The advantage of this version of rename over standard SFTP rename is that it is an atomic operation and will allow renaming a resource where the destination name exists. The POSIX rename will also work on some file systems which do not support standard SFTP rename because they don't support the system hardlink() call. The POSIX rename extension is available on all openSSH servers from 4.8 and some other implementations. This is an extension to the standard SFTP protocol and therefore is not supported on all sftp servers.
792
776
 
793
777
  - **fromPath:** string. Path to existing file to be renamed.
794
778
  - **toPath:** string. Path for new name. If it already exists, it will be replaced by file specified in fromPath
795
779
 
796
780
  ```javascript
781
+
782
+ let
783
+
797
784
  let from = '/remote/path/to/old.txt';
798
785
  let to = '/remote/path/to/new.txt';
799
786
  let client = new Client();
@@ -810,10 +797,7 @@ client.connect(config)
810
797
  });
811
798
  ```
812
799
 
813
-
814
- <a id="org02d64a4"></a>
815
-
816
- ### chmod(path, mode) ==> string
800
+ ### chmod(path, mode) ==> string<a id="sec-4-2-16"></a>
817
801
 
818
802
  Change the mode (read, write or execute permissions) of a remote file or directory.
819
803
 
@@ -823,6 +807,9 @@ Change the mode (read, write or execute permissions) of a remote file or directo
823
807
  1. Example Use
824
808
 
825
809
  ```javascript
810
+
811
+ let
812
+
826
813
  let path = '/path/to/remote/file.txt';
827
814
  let newMode = 0o644; // rw-r-r
828
815
  let client = new Client();
@@ -839,10 +826,7 @@ Change the mode (read, write or execute permissions) of a remote file or directo
839
826
  });
840
827
  ```
841
828
 
842
-
843
- <a id="org008d567"></a>
844
-
845
- ### realPath(path) ===> string
829
+ ### realPath(path) ===> string<a id="sec-4-2-17"></a>
846
830
 
847
831
  Converts a relative path to an absolute path on the remote server. This method is mainly used internally to resolve remote path names.
848
832
 
@@ -850,17 +834,11 @@ Converts a relative path to an absolute path on the remote server. This method i
850
834
 
851
835
  - **path:** A file path, either relative or absolute. Can handle '.' and '..', but does not expand '~'.
852
836
 
853
-
854
- <a id="org7033d28"></a>
855
-
856
- ### cwd() ==> string
837
+ ### cwd() ==> string<a id="sec-4-2-18"></a>
857
838
 
858
839
  Returns what the server believes is the current remote working directory.
859
840
 
860
-
861
- <a id="orgfa0102a"></a>
862
-
863
- ### uploadDir(srcDir, dstDir, options) ==> string
841
+ ### uploadDir(srcDir, dstDir, options) ==> string<a id="sec-4-2-19"></a>
864
842
 
865
843
  Upload the directory specified by `srcDir` to the remote directory specified by `dstDir`. The `dstDir` will be created if necessary. Any sub directories within `srcDir` will also be uploaded. Any existing files in the remote path will be overwritten.
866
844
 
@@ -879,61 +857,61 @@ The `useFastput` option is a boolean option. If `true`, the method will use the
879
857
  1. Example
880
858
 
881
859
  ```javascript
882
- 'use strict';
883
860
 
884
- // Example of using the uploadDir() method to upload a directory
885
- // to a remote SFTP server
886
861
 
887
- const path = require('path');
888
- const SftpClient = require('../src/index');
889
862
 
890
- const dotenvPath = path.join(__dirname, '..', '.env');
891
- require('dotenv').config({path: dotenvPath});
863
+ 'use strict';
892
864
 
893
- const config = {
894
- host: process.env.SFTP_SERVER,
895
- username: process.env.SFTP_USER,
896
- password: process.env.SFTP_PASSWORD,
897
- port: process.env.SFTP_PORT || 22
898
- };
865
+ // Example of using the uploadDir() method to upload a directory
866
+ // to a remote SFTP server
899
867
 
900
- async function main() {
901
- const client = new SftpClient('upload-test');
902
- const src = path.join(__dirname, '..', 'test', 'testData', 'upload-src');
903
- const dst = '/home/tim/upload-test';
868
+ const path = require('path');
869
+ const SftpClient = require('../src/index');
904
870
 
905
- try {
906
- await client.connect(config);
907
- client.on('upload', info => {
908
- console.log(`Listener: Uploaded ${info.source}`);
909
- });
910
- let rslt = await client.uploadDir(src, dst);
911
- return rslt;
912
- } catch (err) {
913
- console.error(err);
914
- } finally {
915
- client.end();
916
- }
917
- }
871
+ const dotenvPath = path.join(__dirname, '..', '.env');
872
+ require('dotenv').config({path: dotenvPath});
918
873
 
919
- main()
920
- .then(msg => {
921
- console.log(msg);
922
- })
923
- .catch(err => {
924
- console.log(`main error: ${err.message}`);
925
- });
874
+ const config = {
875
+ host: process.env.SFTP_SERVER,
876
+ username: process.env.SFTP_USER,
877
+ password: process.env.SFTP_PASSWORD,
878
+ port: process.env.SFTP_PORT || 22
879
+ };
880
+
881
+ async function main() {
882
+ const client = new SftpClient('upload-test');
883
+ const src = path.join(__dirname, '..', 'test', 'testData', 'upload-src');
884
+ const dst = '/home/tim/upload-test';
885
+
886
+ try {
887
+ await client.connect(config);
888
+ client.on('upload', info => {
889
+ console.log(`Listener: Uploaded ${info.source}`);
890
+ });
891
+ let rslt = await client.uploadDir(src, dst);
892
+ return rslt;
893
+ } catch (err) {
894
+ console.error(err);
895
+ } finally {
896
+ client.end();
897
+ }
898
+ }
899
+
900
+ main()
901
+ .then(msg => {
902
+ console.log(msg);
903
+ })
904
+ .catch(err => {
905
+ console.log(`main error: ${err.message}`);
906
+ });
926
907
 
927
908
  ```
928
909
 
929
-
930
- <a id="orgefe6fc6"></a>
931
-
932
- ### downloadDir(srcDir, dstDir, options) ==> string
910
+ ### downloadDir(srcDir, dstDir, options) ==> string<a id="sec-4-2-20"></a>
933
911
 
934
912
  Download the remote directory specified by `srcDir` to the local file system directory specified by `dstDir`. The `dstDir` directory will be created if required. All sub directories within `srcDir` will also be copied. Any existing files in the local path will be overwritten. No files in the local path will be deleted.
935
913
 
936
- The method also emites `download` events to provide a way to monitor download progress. The download event listener is called with one argument, an object with two properties, source and destination. The source property is the path to the remote file that has been downloaded and the destination is the local path to where the file was downloaded to. You can add a listener for this event using the `on()` method.
914
+ The method also emits `download` events to provide a way to monitor download progress. The download event listener is called with one argument, an object with two properties, source and destination. The source property is the path to the remote file that has been downloaded and the destination is the local path to where the file was downloaded to. You can add a listener for this event using the `on()` method.
937
915
 
938
916
  The `options` argument is an options object with two supported properties, `filter` and `useFastget`. The `filter` argument is a predicate function which will be called with two arguments for each potential item to be downloaded. The first argument is the full path of the item and the second argument is a boolean, which will be true if the item is a directory. If the function returns true, the item will be included in the download. If it returns false, it will be filtered and ignored. The filter function is called via the `Array.filter` method. These array comprehension methods are known to be unsafe for asynchronous functions. Therefore, only synchronous filter functions are supported at this time.
939
917
 
@@ -941,11 +919,14 @@ If the `useFastget` property is set to `true`, the method will use `fastGet()` t
941
919
 
942
920
  - **srcDir:** A remote file path specified as a string
943
921
  - **dstDir:** A local file path specified as a string
944
- - **options:** An object with two supported properties, `filter` and `useFastget`. The filter property is a function accepting two arguments, the full path to an item and a boolean value which will be true if the item is a directory. The function is called for each item in the download path and should return true to include the item and false to exclude it in the download. The `useFastget` property is a boolean. If true, the `fastGet()` method will be used to transfer files. If `false` (the default), the slower but better supported `get()` mehtod is used. .
922
+ - **options:** An object with two supported properties, `filter` and `useFastget`. The filter property is a function accepting two arguments, the full path to an item and a boolean value which will be true if the item is a directory. The function is called for each item in the download path and should return true to include the item and false to exclude it in the download. The `useFastget` property is a boolean. If true, the `fastGet()` method will be used to transfer files. If `false` (the default), the slower but better supported `get()` method is used. .
945
923
 
946
924
  1. Example
947
925
 
948
926
  ```javascript
927
+
928
+ 'use
929
+
949
930
  'use strict';
950
931
 
951
932
  // Example of using the downloadDir() method to upload a directory
@@ -991,10 +972,7 @@ If the `useFastget` property is set to `true`, the method will use `fastGet()` t
991
972
 
992
973
  ```
993
974
 
994
-
995
- <a id="org783e363"></a>
996
-
997
- ### createReadStream(remotePath, options)) ==> stream object
975
+ ### createReadStream(remotePath, options)) ==> stream object<a id="sec-4-2-21"></a>
998
976
 
999
977
  Returns a read stream object which is attached to the remote file specified by the `remotePath` argument. This is a low level method which just returns a read stream object. Client code is fully responsible for managing and releasing the resources associated with the stream once finished i.e. closing files, removing listeners etc.
1000
978
 
@@ -1006,43 +984,37 @@ Returns a read stream object which is attached to the remote file specified by t
1006
984
  - **mode:** 0o666
1007
985
  - **autoClose:** defaults to true. If set to false, client code is responsible for closing file descriptors when finished
1008
986
  - **start:** Default 0. Position to start reading bytes from (inclusive)
1009
- - **end:** Postion to stop reading bytes (inclusive).
987
+ - **end:** Position to stop reading bytes (inclusive).
1010
988
 
989
+ ### createWriteStream(remotePath, options) ==> stream object<a id="sec-4-2-22"></a>
1011
990
 
1012
- <a id="orgf45313d"></a>
1013
-
1014
- ### createWriteStream(remotePath, options) ==> stream object
1015
-
1016
- Returns a write stream object which is attached to the remote file specified in the `remotePath` argument. This is a low legvel function which just returns the stream object. Client code is fully responsible for managing that object, including closing any file descriptiors and removing listeners etc.
991
+ Returns a write stream object which is attached to the remote file specified in the `remotePath` argument. This is a low level function which just returns the stream object. Client code is fully responsible for managing that object, including closing any file descriptors and removing listeners etc.
1017
992
 
1018
993
  - **remotePath:** Path to the remote file specified as a string
1019
994
  - **options:** An object containing stream options. Supported properties include
1020
995
  - **flags:** default 'w'
1021
- - **encoding:** defulat null
996
+ - **encoding:** default null
1022
997
  - **mode:** 0o666
1023
998
  - **autoClose:** true
1024
999
  - **start:** Byte position to start writing from (inclusive). May require changing flag to 'r+'.
1025
1000
 
1001
+ ### rcopy(srcPath, dstPath) ==> string<a id="sec-4-2-23"></a>
1026
1002
 
1027
- <a id="orga31c8c1"></a>
1028
-
1029
- ### rcopy(srcPath, dstPath) ==> string
1030
-
1031
- Perfrom a remote file copy. The file identified by the `srcPath` argument will be copied to the file specified as the `dstPath` argument. The directory where `dstPath` will be placed must exist, but the actual file must not i.e. no overwrites allowed.
1003
+ Perform a remote file copy. The file identified by the `srcPath` argument will be copied to the file specified as the `dstPath` argument. The directory where `dstPath` will be placed must exist, but the actual file must not i.e. no overwrites allowed.
1032
1004
 
1033
1005
  - **srcPath:** Path to remote file to be copied specified as a string
1034
- - **dstPath:** Path to where the copy will be creaeted specified as a string
1006
+ - **dstPath:** Path to where the copy will be created specified as a string
1035
1007
 
1036
-
1037
- <a id="org4d02fde"></a>
1038
-
1039
- ### end() ==> boolean
1008
+ ### end() ==> boolean<a id="sec-4-2-24"></a>
1040
1009
 
1041
1010
  Ends the current client session, releasing the client socket and associated resources. This function also removes all listeners associated with the client.
1042
1011
 
1043
1012
  1. Example Use
1044
1013
 
1045
1014
  ```javascript
1015
+
1016
+ let
1017
+
1046
1018
  let client = new Client();
1047
1019
 
1048
1020
  client.connect(config)
@@ -1057,10 +1029,7 @@ Ends the current client session, releasing the client socket and associated reso
1057
1029
  });
1058
1030
  ```
1059
1031
 
1060
-
1061
- <a id="orge5769d3"></a>
1062
-
1063
- ### Add and Remove Listeners
1032
+ ### Add and Remove Listeners<a id="sec-4-2-25"></a>
1064
1033
 
1065
1034
  Although normally not required, you can add and remove custom listeners on the ssh2 client object. This object supports a number of events, but only a few of them have any meaning in the context of SFTP. These are
1066
1035
 
@@ -1078,73 +1047,55 @@ Although normally not required, you can add and remove custom listeners on the s
1078
1047
 
1079
1048
  Removes the specified listener from the event specified in eventType. Note that the `end()` method automatically removes all listeners from the client object.
1080
1049
 
1050
+ # Platform Quirks & Warnings<a id="sec-5"></a>
1081
1051
 
1082
- <a id="org3e6ddf9"></a>
1083
-
1084
- # Platform Quirks & Warnings
1085
-
1052
+ ## Server Capabilities<a id="sec-5-1"></a>
1086
1053
 
1087
- <a id="org61f0fe5"></a>
1088
-
1089
- ## Server Capabilities
1090
-
1091
- All SFTP servers and platforms are not equal. Some facilities provided by `ssh2-sftp-client` either depend on capabilities of the remote server or the underlying capabilities of the remote server platform. As an example, consider `chmod()`. This command depends on a remote filesystem which implements the 'nix' concept of users and groups. The *win32* platform does not have the same concept of users and groups, so `chmod()` will not behave in the same way.
1054
+ All SFTP servers and platforms are not equal. Some facilities provided by `ssh2-sftp-client` either depend on capabilities of the remote server or the underlying capabilities of the remote server platform. As an example, consider `chmod()`. This command depends on a remote file system which implements the 'nix' concept of users and groups. The *win32* platform does not have the same concept of users and groups, so `chmod()` will not behave in the same way.
1092
1055
 
1093
1056
  One way to determine whether an issue you are encountering is due to `ssh2-sftp-client` or due to the remote server or server platform is to use a simple CLI sftp program, such as openSSH's sftp command. If you observe the same behaviour using plain `sftp` on the command line, the issue is likely due to server or remote platform limitations. Note that you should not use a GUI sftp client, like `Filezilla` or `winSCP` as such GUI programs often attempt to hide these server and platform incompatibilities and will take additional steps to simulate missing functionality etc. You want to use a CLI program which does as little as possible.
1094
1057
 
1058
+ ## Issues with `fastPut()` and `fastGet()` Methods<a id="sec-5-2"></a>
1095
1059
 
1096
- <a id="orga7d6067"></a>
1060
+ The `fastPut()` and `fastGet()` methods are known to be somewhat dependent on SFTP server capabilities. Some SFTP servers just do not work correctly with concurrent connections and some are known to have issues with negotiating packet sizes. These issues can sometimes be resolved by tweaking the options supplied to the methods, such as setting number of concurrent connections or a specific packet size.
1097
1061
 
1098
- ## Promises, Events & Managing Exceptions
1062
+ To see an example of the type of issues you can observe with `fastPut()` or `fastGet()`, have a look at [issue 407](https://github.com/theophilusx/ssh2-sftp-client/issues/407), which describes the experiences of one user. Bottom line, when it works, it tends to work well and be significantly faster than using just `get()` or `put()`. However, when developing code to run against different SFTP servers, especially where you are unable to test against each server, you are likely better off just using `get()` and `put()` or structuring your code so that users can select which method to use (this is what `ssh2-sftp-client` does - for example, see the `!downloadDir()` and `uploadDir()` methods.
1063
+
1064
+ ## Promises, Events & Managing Exceptions<a id="sec-5-3"></a>
1099
1065
 
1100
1066
  One of the challenges in providing a Promise based API over a module like SSH2, which is event based is how to ensure events are handled appropriately. The challenge is due to the synchronous nature of events. You cannot use `try/catch` for events because you have no way of knowing when the event might fire. For example, it could easily fire after your `try/catch` block as completed execution.
1101
1067
 
1102
- Things become even more complicated once you mix in Promises. When you define a promise, you have to methods which can be called to fulfil a promise, `resolve` and `reject`. Only one can be called - once you call `resolve`, you cannot call `reject` (well, you can call it, but it won't have any impact on the fulfilment status of the promise). The problem arises when an event, for exmaple an `error` event is fired either after you have resolved a promise or possibly in-between promises. If you don't catch the `error` event, your script will likely crash with an `uncaught exception` error.
1068
+ Things become even more complicated once you mix in Promises. When you define a promise, you have to methods which can be called to fulfil a promise, `resolve` and `reject`. Only one can be called - once you call `resolve`, you cannot call `reject` (well, you can call it, but it won't have any impact on the fulfilment status of the promise). The problem arises when an event, for example an `error` event is fired either after you have resolved a promise or possibly in-between promises. If you don't catch the `error` event, your script will likely crash with an `uncaught exception` error.
1103
1069
 
1104
1070
  To make matters worse, some servers, particularly servers running on a Windows platform, will raise multiple errors for the same error *event*. For example, when you attempt to connect with a bad username or password, you will get a `All authentication methods have failed` exception. However, under Windows, you will also get a `Connection reset by peer` exception. If we reject the connect promise based on the authentication failure exception, what do we do with the `reset by peer` exception? More critically, what will handle that exception given the promise has already been fulfilled and completed? To make matters worse, it seems that Windows based servers also raise an error event for *non-errors*. For example, when you call the `end()` method, the connection is closed. On windows, this also results in a *connection reset by peer* error. While it could be argued that the remote server resetting the connection after receiving a disconnect request is not an error, it doesn't change the fact that one is raised and we need to somehow deal with it.
1105
1071
 
1106
- To handle this, `ssh2-sftp-client` implements a couple of strategies. Firstly, when you call one of the module's methods, it adds `error`, `end` and `close` event listeners which will call the `reject` moethod on the enclosing promise. It also keeps track of whether an error has been handled and if it has, it ignores any subsequent errors until the promise ends. Typically, the first error caught has the most relevant information and any subsequent error events are less critical or informative, so ignoring them has no negative impact. Provided one of the events is raised before the promise is fulfilled, these handlers will consume the event and deal with it appropriately.
1072
+ To handle this, `ssh2-sftp-client` implements a couple of strategies. Firstly, when you call one of the module's methods, it adds `error`, `end` and `close` event listeners which will call the `reject` method on the enclosing promise. It also keeps track of whether an error has been handled and if it has, it ignores any subsequent errors until the promise ends. Typically, the first error caught has the most relevant information and any subsequent error events are less critical or informative, so ignoring them has no negative impact. Provided one of the events is raised before the promise is fulfilled, these handlers will consume the event and deal with it appropriately.
1107
1073
 
1108
1074
  In testing, it was found that in some situations, particularly during connect operations, subsequent errors fired with a small delay. This prevents the errors from being handled by the event handlers associated with the connect promise. To deal with this, a small 500ms delay has been added to the connect() method, which effectively delays the removal of the event handlers until all events have been caught.
1109
1075
 
1110
- The other area where additional events are fired is during the end() call. To deal with these events, the `end()` method setus up listeners which will simply ignore additional `error`, `end` and `close` events. It is assumed that once you have called `end()` you really only care about any main error which occurs and no longer care about other errors that may be raised as the connection is terminated.
1076
+ The other area where additional events are fired is during the end() call. To deal with these events, the `end()` method sets up listeners which will simply ignore additional `error`, `end` and `close` events. It is assumed that once you have called `end()` you really only care about any main error which occurs and no longer care about other errors that may be raised as the connection is terminated.
1111
1077
 
1112
1078
  In addition to the promise based event handlers, `ssh2-sftp-client` also implements global event handlers which will catch any `error`, `end` or `close` events. Essentially, these global handlers only reset the `sftp` property of the client object, effectively ensuring any subsequent calls are rejected and in the case of an error, send the error to the console.
1113
1079
 
1114
-
1115
- <a id="orgc08d427"></a>
1116
-
1117
- ### Adding Custom Handlers
1080
+ ### Adding Custom Handlers<a id="sec-5-3-1"></a>
1118
1081
 
1119
1082
  While the above strategies appear to work for the majority of use cases, there are always going to be edge cases which require more flexible or powerful event handling. To support this, the `on()` and `removeListener()` methods are provided. Any event listener added using the `on()` method will be added at the beginning of the list of handlers for that event, ensuring it will be called before any global or promise local events. See the documentation for the `on()` method for details.
1120
1083
 
1121
-
1122
- <a id="org5439468"></a>
1123
-
1124
- ## Windows Based Servers
1084
+ ## Windows Based Servers<a id="sec-5-4"></a>
1125
1085
 
1126
1086
  It appears that when the sftp server is running on Windows, a *ECONNRESET* error signal is raised when the end() method is called. Unfortunately, this signal is raised after a considerable delay. This means we cannot remove the error handler used in the end() promise as otherwise you will get an uncaught exception error. Leaving the handler in place, even though we will ignore this error, solves that issue, but unfortunately introduces a new problem. Because we are not removing the listener, if you re-use the client object for subsequent connections, an additional error handler will be added. If this happens more than 11 times, you will eventually see the Node warning about a possible memory leak. This is because node monitors the number of error handlers and if it sees more than 11 added to an object, it assumes there is a problem and generates the warning.
1127
1087
 
1128
1088
  The best way to avoid this issue is to not re-use client objects. Always generate a new sftp client object for each new connection.
1129
1089
 
1130
-
1131
- <a id="orgae9129c"></a>
1132
-
1133
- ## Don't Re-use SftpClient Objects
1090
+ ## Don't Re-use SftpClient Objects<a id="sec-5-5"></a>
1134
1091
 
1135
1092
  Due to an issue with *ECONNRESET* error signals when connecting to Windows based SFTP servers, it is not possible to remove the error handler in the end() method. This means that if you re-use the SftpClient object for multiple connections e.g. calling connect(), then end(), then connect() etc, you run the risk of multiple error handlers being added to the SftpClient object. After 11 handlers have been added, Node will generate a possible memory leak warning.
1136
1093
 
1137
1094
  To avoid this problem, don't re-use SftpClient objects. Generate a new SftpClient object for each connection. You can perform multiple actions with a single connection e.g. upload multiple files, download multiple files etc, but after you have called end(), you should not try to re-use the object with a further connect() call. Create a new object instead.
1138
1095
 
1096
+ # FAQ<a id="sec-6"></a>
1139
1097
 
1140
- <a id="org3761660"></a>
1141
-
1142
- # FAQ
1143
-
1144
-
1145
- <a id="org1e669d1"></a>
1146
-
1147
- ## Remote server drops connections with only an end event
1098
+ ## Remote server drops connections with only an end event<a id="sec-6-1"></a>
1148
1099
 
1149
1100
  Many SFTP servers have rate limiting protection which will drop connections once a limit has been reached. In particular, openSSH has the setting `MaxStartups`, which can be a tuple of the form `max:drop:full` where `max` is the maximum allowed unauthenticated connections, `drop` is a percentage value which specifies percentage of connections to be dropped once `max` connections has been reached and `full` is the number of connections at which point all subsequent connections will be dropped. e.g. `10:30:60` means allow up to 10 unauthenticated connections after which drop 30% of connection attempts until reaching 60 unauthenticated connections, at which time, drop all attempts.
1150
1101
 
@@ -1152,16 +1103,16 @@ Clients first make an unauthenticated connection to the SFTP server to begin neg
1152
1103
 
1153
1104
  One way to avoid this type of issue is to add a delay between connection attempts. It does not need to be a very long delay - just sufficient to permit the previous connection to be authenticated. In fact, the default setting for openSSH is `10:30:60`, so you really just need to have enough delay to ensure that the 1st connection has completed authentication before the 11th connection is attempted.
1154
1105
 
1155
-
1156
- <a id="org71d5bab"></a>
1157
-
1158
- ## How can I pass writable stream as dst for get method?
1106
+ ## How can I pass writeable stream as dst for get method?<a id="sec-6-2"></a>
1159
1107
 
1160
1108
  If the dst argument passed to the get method is a writeable stream, the remote file will be piped into that writeable. If the writeable you pass in is a writeable stream created with `fs.createWriteStream()`, the data will be written to the file specified in the constructor call to `createWriteStream()`.
1161
1109
 
1162
1110
  The writeable stream can be any type of write stream. For example, the below code will convert all the characters in the remote file to upper case before it is saved to the local file system. This could just as easily be something like a gunzip stream from `zlib`, enabling you to decompress remote zipped files as you bring them across before saving to local file system.
1163
1111
 
1164
1112
  ```javascript
1113
+
1114
+ 'use
1115
+
1165
1116
  'use strict';
1166
1117
 
1167
1118
  // Example of using a writeable with get to retrieve a file.
@@ -1211,16 +1162,16 @@ sftp
1211
1162
  });
1212
1163
  ```
1213
1164
 
1214
-
1215
- <a id="orgaafc964"></a>
1216
-
1217
- ## How can I upload files without having to specify a password?
1165
+ ## How can I upload files without having to specify a password?<a id="sec-6-3"></a>
1218
1166
 
1219
1167
  There are a couple of ways to do this. Essentially, you want to setup SSH keys and use these for authentication to the remote server.
1220
1168
 
1221
1169
  One solution, provided by @KalleVuorjoki is to use the SSH agent process. **Note**: SSH<sub>AUTH</sub><sub>SOCK</sub> is normally created by your OS when you load the ssh-agent as part of the login session.
1222
1170
 
1223
1171
  ```javascript
1172
+
1173
+ let
1174
+
1224
1175
  let sftp = new Client();
1225
1176
  sftp.connect({
1226
1177
  host: 'YOUR-HOST',
@@ -1235,6 +1186,9 @@ sftp.connect({
1235
1186
  Another alternative is to just pass in the SSH key directly as part of the configuration.
1236
1187
 
1237
1188
  ```javascript
1189
+
1190
+ let
1191
+
1238
1192
  let sftp = new Client();
1239
1193
  sftp.connect({
1240
1194
  host: 'YOUR-HOST',
@@ -1246,14 +1200,14 @@ sftp.connect({
1246
1200
  }
1247
1201
  ```
1248
1202
 
1249
-
1250
- <a id="orgebf85e2"></a>
1251
-
1252
- ## How can I connect through a Socks Proxy
1203
+ ## How can I connect through a Socks Proxy<a id="sec-6-4"></a>
1253
1204
 
1254
1205
  This solution was provided by @jmorino.
1255
1206
 
1256
1207
  ```javascript
1208
+
1209
+ import
1210
+
1257
1211
  import { SocksClient } from 'socks';
1258
1212
  import SFTPClient from 'ssh2-sftp-client';
1259
1213
 
@@ -1282,59 +1236,59 @@ client.connect({
1282
1236
  // client is connected
1283
1237
  ```
1284
1238
 
1239
+ ## Timeout while waiting for handshake or handshake errors<a id="sec-6-5"></a>
1285
1240
 
1286
- <a id="org528d9ea"></a>
1241
+ Some users have encountered the error 'Timeout while waiting for handshake' or 'Handshake failed, no matching client->server ciphers. This is often due to the client not having the correct configuration for the transport layer algorithms used by ssh2. One of the connect options provided by the ssh2 module is `algorithm`, which is an object that allows you to explicitly set the key exchange, ciphers, hmac and compression algorithms as well as server host key used to establish the initial secure connection. See the SSH2 documentation for details. Getting these parameters correct usually resolves the issue.
1287
1242
 
1288
- ## Timeout while waiting for handshake or handshake errors
1243
+ When encountering this type of problem, one worthwhile approach is to use openSSH's CLI sftp program with the `-v` switch to raise logging levels. This will show you what algorithms the CLI is using. You can then use this information to match the names with the accepted algorithm names documented in the `ssh2` README to set the properties in the `algorithms` object.
1289
1244
 
1290
- Some users have encountered the error 'Timeout while waiting for handshake' or 'Handshake failed, no matching client->server ciphers. This is often due to the client not having the correct configuration for the transport layer algorithms used by ssh2. One of the connect options provided by the ssh2 module is `algorithm`, which is an object that allows you to explicitly set the key exchange, ciphers, hmac and compression algorithms as well as server host key used to establish the initial secure connection. See the SSH2 documentation for details. Getting these parameters correct usually resolves the issue.
1245
+ ## How can I limit upload/download speed<a id="sec-6-6"></a>
1291
1246
 
1292
- When encountering this type of problem, one worthwhile approach is to use openSSH's CLI sftp program with the `-v` switch to raise loggin levels. This will show you what algorithms the CLI is using. You can then use this information to match the names with the accepted algorithm names documented in the `ssh2` README to set the properties in the `algorithms` object.
1247
+ If you want to limit the amount of bandwidth used during upload/download of data, you can use a stream to limit throughput. The following example was provided by *kennylbj*. Note that there is a caveat that we must set the `autoClose` flag to false to avoid calling an extra `_read()` on a closed stream that may cause \_get Permission Denied error in ssh2-streams.
1293
1248
 
1249
+ ```javascript
1294
1250
 
1295
- <a id="org3b6ff20"></a>
1296
1251
 
1297
- ## How can I limit upload/download speed
1298
1252
 
1299
- If you want to limit the amount of bandwidth used during upload/download of data, you can use a stream to limit throughput. The following example was provided by *kennylbj*. Note that there is a caveat that we must set the `autoClose` flag to false to avoid calling an extra `_read()` on a closed stream that may cause \_get Permission Denied error in ssh2-streams.
1300
1253
 
1301
- ```javascript
1302
1254
 
1303
1255
 
1304
- const Throttle = require('throttle');
1305
- const progress = require('progress-stream');
1306
1256
 
1307
- // limit download speed
1308
- const throttleStream = new Throttle(config.throttle);
1309
1257
 
1310
- // download progress stream
1311
- const progressStream = progress({
1312
- length: fileSize,
1313
- time: 500,
1314
- });
1315
- progressStream.on('progress', (progress) => {
1316
- console.log(progress.percentage.toFixed(2));
1317
- });
1318
1258
 
1319
- const outStream = createWriteStream(localPath);
1320
1259
 
1321
- // pipe streams together
1322
- throttleStream.pipe(progressStream).pipe(outStream);
1323
1260
 
1324
- try {
1325
- // set autoClose to false
1326
- await client.get(remotePath, throttleStream, { autoClose: false });
1327
- } catch (e) {
1328
- console.log('sftp error', e);
1329
- } finally {
1330
- await client.end();
1331
- }
1332
- ```
1261
+ const Throttle = require('throttle');
1262
+ const progress = require('progress-stream');
1263
+
1264
+ // limit download speed
1265
+ const throttleStream = new Throttle(config.throttle);
1266
+
1267
+ // download progress stream
1268
+ const progressStream = progress({
1269
+ length: fileSize,
1270
+ time: 500,
1271
+ });
1272
+ progressStream.on('progress', (progress) => {
1273
+ console.log(progress.percentage.toFixed(2));
1274
+ });
1275
+
1276
+ const outStream = createWriteStream(localPath);
1333
1277
 
1278
+ // pipe streams together
1279
+ throttleStream.pipe(progressStream).pipe(outStream);
1334
1280
 
1335
- <a id="orgb5e285f"></a>
1281
+ try {
1282
+ // set autoClose to false
1283
+ await client.get(remotePath, throttleStream, { autoClose: false });
1284
+ } catch (e) {
1285
+ console.log('sftp error', e);
1286
+ } finally {
1287
+ await client.end();
1288
+ }
1289
+ ```
1336
1290
 
1337
- ## Connection hangs or fails for larger files
1291
+ ## Connection hangs or fails for larger files<a id="sec-6-7"></a>
1338
1292
 
1339
1293
  This was contributed by Ladislav Jacho. Thanks.
1340
1294
 
@@ -1342,17 +1296,11 @@ A symptom of this issue is that you are able to upload small files, but uploadin
1342
1296
 
1343
1297
  For more explanation, see [issue #342](https://github.com/theophilusx/ssh2-sftp-client/issues/342).
1344
1298
 
1345
-
1346
- <a id="org18ce0c2"></a>
1347
-
1348
- # Examples
1299
+ # Examples<a id="sec-7"></a>
1349
1300
 
1350
1301
  I have started collecting example scripts in the example directory of the repository. These are mainly scripts I have put together in order to investigate issues or provide samples for users. They are not robust, lack adequate error handling and may contain errors. However, I think they are still useful for helping developers see how the module and API can be used.
1351
1302
 
1352
-
1353
- <a id="orgf4b6c80"></a>
1354
-
1355
- # Troubleshooting
1303
+ # Troubleshooting<a id="sec-8"></a>
1356
1304
 
1357
1305
  The `ssh2-sftp-client` module is essentially a wrapper around the `ssh2` and `ssh2-streams` modules, providing a higher level `promise` based API. When you run into issues, it is important to try and determine where the issue lies - either in the ssh2-sftp-client module or the underlying `ssh2` and `ssh2-streams` modules. One way to do this is to first identify a minimal reproducible example which reproduces the issue. Once you have that, try to replicate the functionality just using the `ssh2` and `ssh2-streams` modules. If the issue still occurs, then you can be fairly confident it is something related to those later 2 modules and therefore and issue which should be referred to the maintainer of that module.
1358
1306
 
@@ -1364,21 +1312,18 @@ Note also that in the repository there are two useful directories. The first is
1364
1312
 
1365
1313
  The second directory is the validation directory. I have some very simple scripts in this directory which perform basic tasks using only the `ssh2` modules (no `ssh2-sftp-client` module). These can be useful when trying to determine if the issue is with the underlying `ssh2` module or the `ssh2-sftp-client` wrapper module.
1366
1314
 
1315
+ ## Common Errors<a id="sec-8-1"></a>
1367
1316
 
1368
- <a id="orga419582"></a>
1369
-
1370
- ## Common Errors
1317
+ There are some common errors people tend to make when using Promises or Async/Await. These are by far the most common problem found in issues logged against this module. Please check for some of these before logging your issue.
1371
1318
 
1372
- There are some common errors people tend to make when using Promises or Asyc/Await. These are by far the most common problem found in issues logged against this module. Please check for some of these before logging your issue.
1319
+ ### Not returning the promise in a `then()` block<a id="sec-8-1-1"></a>
1373
1320
 
1321
+ All methods in `ssh2-sftp-client` return a Promise. This means methods are executed *asynchrnously*. When you call a method inside the `then()` block of a promise chain, it is critical that you return the Promise that call generates. Failing to do this will result in the `then()` block completing and your code starting execution of the next `then()`, `catch()` or `finally()` block before your promise has been fulfilled. For example, the following will not do what you expect
1374
1322
 
1375
- <a id="orgd5f3557"></a>
1323
+ ```javascript
1376
1324
 
1377
- ### Not returning the promise in a `then()` block
1378
1325
 
1379
- All methods in `ssh2-sftp-client` return a Promise. This means methods are executed *asynchrnously*. When you call a method inside the `then()` block of a promise chain, it is critical that you return the Promise that call generates. Failing to do this will result in the `then()` block completing and your code starting execution of the next `then()`, `catch()` or `finally()` block before your promise has been fulfilled. For example, the following will not do what you expect
1380
1326
 
1381
- ```javascript
1382
1327
  sftp.connect(config)
1383
1328
  .then(() => {
1384
1329
  sftp.fastGet('foo.txt', 'bar.txt');
@@ -1393,6 +1338,9 @@ sftp.connect(config)
1393
1338
  In the above code, the `sftp.end()` method will almost certainly be called before `sftp.fastGet()` has been fulfilled (unless the *foo.txt* file is really small!). In fact, the whole promise chain will complete and exit even before the `sftp.end()` call has been fulfilled. The correct code would be something like
1394
1339
 
1395
1340
  ```javascript
1341
+
1342
+
1343
+
1396
1344
  sftp.connect(config)
1397
1345
  .then(() => {
1398
1346
  return sftp.fastGet('foo.txt', 'bar.txt');
@@ -1408,14 +1356,14 @@ Note the `return` statements. These ensure that the Promise returned by the clie
1408
1356
 
1409
1357
  A common symptom of this type of error is for file uploads or download to fail to complete or for data in those files to be truncated. What is happening is that the connection is being ended before the transfer has completed.
1410
1358
 
1411
-
1412
- <a id="org557d1c5"></a>
1413
-
1414
- ### Mixing Promise Chains and Async/Await
1359
+ ### Mixing Promise Chains and Async/Await<a id="sec-8-1-2"></a>
1415
1360
 
1416
1361
  Another common error is to mix Promise chains and async/await calls. This is rarely a great idea. While you can do this, it tends to create complicated and difficult to maintain code. Select one approach and stick with it. Both approaches are functionally equivalent, so there is no reason to mix up the two paradigms. My personal preference would be to use async/await as I think that is more *natural* for most developers. For example, the following is more complex and difficult to follow than necessary (and has a bug!)
1417
1362
 
1418
1363
  ```javascript
1364
+
1365
+
1366
+
1419
1367
  sftp.connect(config)
1420
1368
  .then(() => {
1421
1369
  return sftp.cwd();
@@ -1438,6 +1386,9 @@ The main bug in the above code is the `then()` block is not returning the Promis
1438
1386
  Using async/await inside the promise chain has created unnecessary complexity and leads to incorrect assumptions regarding how the code will execute. A quick glance at the code is likely to give the impression that execution will wait for the `sftp.fastGet()` call to be fulfilled before continuing. This is not the case. The code would be more clearly expressed as either
1439
1387
 
1440
1388
  ```javascript
1389
+
1390
+
1391
+
1441
1392
  sftp.connect(config)
1442
1393
  .then(() => {
1443
1394
  return sftp.cwd();
@@ -1454,6 +1405,9 @@ sftp.connect(config)
1454
1405
  **or, using async/await**
1455
1406
 
1456
1407
  ```javascript
1408
+
1409
+
1410
+
1457
1411
  async function doSftp() {
1458
1412
  try {
1459
1413
  let sftp = await sftp.connect(conf);
@@ -1468,41 +1422,32 @@ async function doSftp() {
1468
1422
  }
1469
1423
  ```
1470
1424
 
1471
-
1472
- <a id="org2bf9a3a"></a>
1473
-
1474
- ### Try/catch and Error Handlers
1425
+ ### Try/catch and Error Handlers<a id="sec-8-1-3"></a>
1475
1426
 
1476
1427
  Another common error is to try and use a try/catch block to catch event signals, such as an error event. In general, you cannot use try/catch blocks for asynchronous code and expect errors to be caught by the `catch` block. Handling errors in asynchronous code is one of the key reasons we now have the Promise and async/await frameworks.
1477
1428
 
1478
- The basic problem is that the try/catch block will have completed execution before the asynchronous code has completed. If the asynchronous code has not compleed, then there is a potential for it to raise an error. However, as the try/catch block has already completed, there is no *catch* waiting to catch the error. It will bubble up and probably result in your script exiting with an uncaught exception error.
1429
+ The basic problem is that the try/catch block will have completed execution before the asynchronous code has completed. If the asynchronous code has not completed, then there is a potential for it to raise an error. However, as the try/catch block has already completed, there is no *catch* waiting to catch the error. It will bubble up and probably result in your script exiting with an uncaught exception error.
1479
1430
 
1480
1431
  Error events are essentially asynchronous code. You don't know when such events will fire. Therefore, you cannot use a try/catch block to catch such event errors. Even creating an error handler which then throws an exception won't help as the key problem is that your try/catch block has already executed. There are a number of alternative ways to deal with this situation. However, the key symptom is that you see occasional uncaught error exceptions that cause your script to exit abnormally despite having try/catch blocks in your script. What you need to do is look at your code and find where errors are raised asynchronously and use an event handler or some other mechanism to manage any errors raised.
1481
1432
 
1482
-
1483
- <a id="org89795d7"></a>
1484
-
1485
- ### Server Differences
1433
+ ### Server Differences<a id="sec-8-1-4"></a>
1486
1434
 
1487
1435
  Not all SFTP servers are the same. Like most standards, the SFTP protocol has some level of interpretation and allows different levels of compliance. This means there can be differences in behaviour between different servers and code which works with one server will not work the same with another. For example, the value returned by *realpath* for non-existent objects can differ significantly. Some servers will throw an error for a particular operation while others will just return null, some servers support concurrent operations (such as used by fastGet/fastPut) while others will not and of course, the text of error messages can vary significantly. In particular, we have noticed significant differences across different platforms. It is therefore advisable to do comprehensive testing when the SFTP server is moved to a new platform. This includes moving from to a cloud based service even if the underlying platform remains the same. I have noticed that some cloud platforms can generate unexpected events, possibly related to additional functionality or features associated with the cloud implementation. For example, it appears SFTP servers running under Azure will generate an error event when the connection is closed even when the client has requested the connection be terminated. The same SFTP server running natively on Windows does not appear to exhibit such behaviour.
1488
1436
 
1489
-
1490
- <a id="orgbec08b0"></a>
1491
-
1492
- ### Avoid Concurrent Operations
1437
+ ### Avoid Concurrent Operations<a id="sec-8-1-5"></a>
1493
1438
 
1494
1439
  Technically, SFTP should be able to perform multiple operations concurrently. As node is single threaded, what we a really talking about is running multiple execution contexts as a pool where node will switch contexts when each context is blocked due to things like waiting on network data etc. However, I have found this to be extremely unreliable and of very little benefit from a performance perspective. My recommendation is to therefore avoid executing multiple requests over the same connection in parallel (for example, generating multiple `get()` promises and using something like `Promise.all()` to resolve them.
1495
1440
 
1496
1441
  If you are going to try and perform concurrent operations, you need to test extensively and ensure you are using data which is large enough that context switching does occur (i.e. the request is not completed in a single run). Some SFTP servers will handle concurrent operations better than others.
1497
1442
 
1498
-
1499
- <a id="org124cfc9"></a>
1500
-
1501
- ## Debugging Support
1443
+ ## Debugging Support<a id="sec-8-2"></a>
1502
1444
 
1503
1445
  You can add a `debug` property to the config object passed in to `connect()` to turn on debugging. This will generate quite a lot of output. The value of the property should be a function which accepts a single string argument. For example;
1504
1446
 
1505
1447
  ```javascript
1448
+
1449
+ config.debug
1450
+
1506
1451
  config.debug = msg => {
1507
1452
  console.error(msg);
1508
1453
  };
@@ -1512,26 +1457,23 @@ config.debug = msg => {
1512
1457
  Enabling debugging can generate a lot of output. If you use console.error() as the output (as in the example above), you can redirect the output to a file using shell redirection e.g.
1513
1458
 
1514
1459
  ```shell
1460
+
1461
+ node
1462
+
1515
1463
  node script.js 2> debug.log
1516
1464
 
1517
1465
  ```
1518
1466
 
1519
1467
  If you just want to see debug messages from `ssh2-sftp-client` and exclude debug messages from the underlying `ssh2` and `ssh2-streams` modules, you can filter based on messages which start with 'CLIENT' e.g.
1520
1468
 
1521
- ```javascript
1522
- {
1523
- debug: (msg) => {
1524
- if (msg.startsWith('CLIENT')) {
1525
- console.error(msg);
1526
- }
1527
- }
1528
- }
1469
+ ```nillangnilswitchesnilflags
1470
+ nilbody
1471
+ #+END_SRC
1472
+ *
1473
+ nilbody
1529
1474
  ```
1530
1475
 
1531
-
1532
- <a id="org5f3c941"></a>
1533
-
1534
- # Logging Issues
1476
+ # Logging Issues<a id="sec-9"></a>
1535
1477
 
1536
1478
  Please log an issue for all bugs, questions, feature and enhancement requests. Please ensure you include the module version, node version and platform.
1537
1479
 
@@ -1545,10 +1487,7 @@ I am happy to try and help diagnose and fix any issues you encounter while using
1545
1487
 
1546
1488
  Perhaps the best assistance is a minimal reproducible example of the issue. Once the issue can be readily reproduced, it can usually be fixed very quickly.
1547
1489
 
1548
-
1549
- <a id="org6e82efc"></a>
1550
-
1551
- # Pull Requests
1490
+ # Pull Requests<a id="sec-10"></a>
1552
1491
 
1553
1492
  Pull requests are always welcomed. However, please ensure your changes pass all tests and if you're adding a new feature, that tests for that feature are included. Likewise, for new features or enhancements, please include any relevant documentation updates.
1554
1493
 
@@ -1560,10 +1499,7 @@ This module will adopt a standard semantic versioning policy. Please indicate in
1560
1499
  - **Minor:** Minor change, enhancement or new feature which does not change existing API and will not break existing client code.
1561
1500
  - **Bug Fix:** No change to functionality or features. Simple fix of an existing bug.
1562
1501
 
1563
-
1564
- <a id="org680b5c2"></a>
1565
-
1566
- # Contributors
1502
+ # Contributors<a id="sec-11"></a>
1567
1503
 
1568
1504
  This module was initially written by jyu213. On August 23rd, 2019, theophilusx took over responsibility for maintaining this module. A number of other people have contributed to this module, but until now, this was not tracked. My intention is to credit anyone who contributes going forward.
1569
1505
 
@@ -1582,4 +1518,4 @@ Thanks to the following for their contributions -
1582
1518
  - **Emma Milner:** Contributed fix for put() bug
1583
1519
  - **Witni Davis:** Contributed PR to fix put() RCE when using 'finish' rather than 'close' to resolve promise
1584
1520
  - **Maik Marschner:** Contributed fix for connect() not returning sftp object. Also included test to check for this regression in future.
1585
- - **cakemasher:** Contributed fix for removeTempListeners().
1521
+ - **cakemasher:** Contributed fix for removeTempListeners().