0 votes
by (140 points)

From Linux, I would surround the name that contains a single quote with double quotes. When I try to do this for the string passed to GetFile(), it get an exception: "cannot perform requested operation in current session state".

I am doing this in a .cpp file as part of a project that has a mix of c++ and c#:

String^ filename = "\"" + srcFile + "\"";
m_scp->GetFile(filename, m_stream);

Using single quotes instead seems to work for other embedded characters in the file name (such as parentheses), but of course does not work for embedded single quotes.

1 Answer

0 votes
by (148k points)
edited by

Quoting of the file name is actually supposed to be done by our API (inside the GetFile method). If you do it yourself, GetFile would consider those quotes to be a part of the file name and quote them again, which would lead to wrong results. So please try just calling m_scp->GetFile(srcFile, m_stream) instead.

However, checking the actual behavior, I noticed that our API is actually not handling single quotes, which seems to be a bug. It's strange it went unnoticed for so long. Apparently, filenames with single quotes are quite rare, and we know that Scp class is used much less often than Sftp. Thanks for bringing this issue to our attention, we will look into it and resolve it for the next release!

(Please discard the second part of the reply above. After double-checking this, is looks like handling of single quotes is actually correct as well. If you encounter any file name that appears to be handled wrongly if passed unquoted, let us know.)

by (140 points)
Thank you for checking this. After updating Rebex to R6.11, this seems to have solved most of the problem. However, I do still see a problem with the '$' character. Files with "$_" or "$$" sequences are not found. The ScpException message shows a file name with these characters either removed or replaced with a number. How can I handle these cases?
by (148k points)
Thanks, there indeed seems to be an issue with "$_" and "$$" sequences. We'll look into this and provide a hotfix as soon as possible!
...