Sftp GetList() finds expected files but returns an invalid path

0 votes
asked Sep 4, 2014 by Jon B (160 points)
edited Dec 31, 2014

I use the GetList() method to identify file(s) to be downloaded from a client's sftp server. Sometimes the path that is passed to GetList() contains wildcards and sometimes it doesn't. For one particular client, when a path is passed in without a wildcard (looking for an exact match) the file is found but SftpItem.Path is incorrect. The path actually contains the correct file path twice separated by "//".

For the path passed into GetList() of root/testfile.txt.1

The returned path is root/testfile.txt.1//root/testfile.txt.1 (Unexpected)

However, if I changed the passed in path to include a wildcard root/testfile.txt*

The returned path is correct root/testfile.txt.1 (Expected)

Does the multiple extensions have something to do with it?

We are not running the latest version, but I noticed two items in the release notes:

SFTP: Added Sftp.Settings.DisableRealPathWorkaround option to disable workaround for WS_FTP SSH_FXP_REALPATH bug.

SFTP: Added workaround for SFTP servers that report duplicate extensions.

Could these be related and where can I get more information about what problems they were meant to fix?

commented Dec 30, 2014 by ganeshspy (900 points)
edited Dec 30, 2014
commented Dec 30, 2014 by Lukas Matyska (56,670 points)
edited Dec 30, 2014

We will look at it.

commented Dec 31, 2014 by ganeshspy (900 points)
edited Dec 31, 2014

Thanks....

2 Answers

0 votes
answered Sep 5, 2014 by Lukas Pokorny (111,330 points)
edited Sep 5, 2014

The duplicate "/" does indeed look like a bug. Which version of Rebex SFTP do you currently use?

The two changes you listd are most likely not related to this (the second one is unrelated for sure). However, the code that constructs the paths for GetList() and related methods has actually been changed substantially in one of the recent releases:

SFTP: GetList and GetInfo return a path in the Path property. SFTP: Fixed SftpItem.Name to return "/" instead of "" for the root folder.

Would it be possible to create a communication log demonstrating the operations that led to the unexpected behavior? That should make it possible for us to easily reproduce and fix it (if it's still present in the latest release).

0 votes
answered Sep 5, 2014 by Jon B (160 points)
edited Dec 18, 2014

I believe we are using 2013 R2 (assembly version 3.0.5085.0).

I can create a log file, where should I put it?

If it wasn't clear in my original post, this is only a problem with a specific client. We are unable to reproduce it on any of our test servers.

commented Sep 5, 2014 by Lukas Pokorny (111,330 points)
edited Sep 5, 2014

That's quite recent - the latest release (2014 R2) would most likely produce the same results.

Either add the log file to your question or mail it to support@rebex.net Thanks! With a log, we should be able to reproduce this even without the specific server.

commented Sep 5, 2014 by Jon B (160 points)
edited Sep 5, 2014

I've sent my logs to support@rebex.net

commented Sep 8, 2014 by Lukas Pokorny (111,330 points)
edited Sep 8, 2014

Thanks for the logs! It looks like this particular server can actually "open a directory" even when passed a file path (unlike most other servers), but then it behaves more like "get file info" instead (and includes full path instead of a file name only). I sent a link to a hotfix that adds a workaround for this to your e-mail. Please give it a try and let us know whether it solves the issue. Thanks for reporting this!

commented Dec 18, 2014 by Lukas Pokorny (111,330 points)
edited Dec 18, 2014

This additional workaround has been added to Rebex SFTP 2014 R3.

...