You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make an SFTP client-like class for SFTP related operations #410
Is your feature request related to a problem? Please describe.
Currently the SFTP related functions are under the SSH clients and also require an SFTP object be passed along with them.
This makes dealing with SFTP difficult, as an SFTP object first needs to be created then passed along to all the various SFTP operations.
Further more, some SFTP operations like mkdir, cd et al are not currently public.
Describe the solution you'd like
Create an SFTP client-like class to handle all SFTP operations in a more user friendly manner.
Under this new class, make all SFTP operations public and easy to use without requiring an SFTP object be passed into them.
Also make this class keep track of current working directory, to go with being able to change directory, make new directories and so forth.
Describe alternatives you've considered
Leaving SFTP as-is, which is less useful.
I went through the open SFTP issues before picking up another change. #394 looks like the smaller compatibility symptom, while this issue covers the broader API design and already supersedes #117.
Would it make sense to treat #410 as the canonical parent and keep #394 as a scoped compatibility subtask? If so, I can use that split for the next triage pass.
Once #410 is implemented, it would also supersede #394. Meaning #394 is not needed if we are working on #410 and should change documentation to use the SFTP specific client instead of the sftp functions in SSHClient.
Those SSHClient functions can be marked as deprecated once #410 is available.
#394 is a small change, I'd favour working on #410 given a choice however.
Activity
lovewave02 commentedon Aug 11, 2026
I went through the open SFTP issues before picking up another change. #394 looks like the smaller compatibility symptom, while this issue covers the broader API design and already supersedes #117.
Would it make sense to treat #410 as the canonical parent and keep #394 as a scoped compatibility subtask? If so, I can use that split for the next triage pass.
pkittenis commentedon Aug 11, 2026
Once #410 is implemented, it would also supersede #394. Meaning #394 is not needed if we are working on #410 and should change documentation to use the SFTP specific client instead of the sftp functions in SSHClient.
Those SSHClient functions can be marked as deprecated once #410 is available.
#394 is a small change, I'd favour working on #410 given a choice however.
Apply verified ParallelSSH PR ParallelSSH#410 patch