5.2.5 Real path and requested remote path do not match

Hi prikryl.

I'm having problems in the last beta 5.2.5 and FTP access, specifically the error seems that only plays when using explicit TLS encryption.

I can reproduce the issue any time:

a) Log in server
b) transfer some files to or from -> work fine
c) Change remote directory
d) try transfer some file from PC -> server.

Sometimes I need repeat this twice, but finally WinSCP fail:

"Real path and requested remote path do not match: "5120 0 16 test.es 17 test.com" "4096 0 16 test.es 17 test.com"
Copying files from remote side failed."

Once WinSCP show that error, any attempt to read, save, transfer... any file to/from server, result in the same error, so I have to restart winSCP.

Attached a failure session. The only change was replace "realhost" with "test". And yes, my tree structure its something like /test.es/test.com

'Old' version work fine, FileZilla or connection without TLS encryption seems work fine too.

Thank in advanced

Same issue here. Using FTP with TLS Explicit Encryption.

When I turn off 'Cache visited remote directories' and 'Cache directory changes' I do not get this error.

Thanks for your posts.

This bug has been added to the tracker:
https://winscp.net/tracker/1078

I'm sending you an email with a development version of WinSCP to address you have used to register on this forum.

Hi prikryl, seen work fine :).

I have not managed to fail even much effort I have put into it.

This bug is also affecting my efforts, so if you could send the development with the fix together with the
.NET assembly to go with it i would be very grateful.

If not then hopefully 5.2.6 will be out soon.

Theliel wrote:

I have not managed to fail even much effort I have put into it.

Thanks for your feedback.

Sharken wrote:

This bug is also affecting my efforts, so if you could send the development with the fix together with the
.NET assembly to go with it i would be very grateful.

Sent.

Thanks a lot for this new version, which no longer has any problem with FTPS sites.
For PowerShell the file transfer progress callback feature is also very cool.

With version 5.2.5 i was trying out AddRawSettings() to workaround the FTPS problem on my own, and
had problems with the username and password.
It turned out i had to add this line to SessionOptions, or else WinSCP would 'forget' the
users password:
$sessionOptions.AddRawSettings("PasswordPlain", $Password)

This details should be stated more clearly in the Documentation (If its not already there).

Once again, thanks for a great FTP library.

One more thing that occurred to me, is that it would be useful if the
Session object had a Reconnect() method.

The way i handled it was to recreate the SessionOptions for a Session-object,
by parsing the Output property and looking for the line starting with 'winscp> open'.
These extracted SessionOptions could then be used for creating a new session object,
which would act exactly as the old session object.
In this case it would have been useful to be able to extract the SessionOptions
from the session object, or some kind of Clone() method on the session object.

Is the absence of Reconnect due to the way WinSCP works ?

Sharken wrote:

With version 5.2.5 i was trying out AddRawSettings() to workaround the FTPS problem on my own, and
had problems with the username and password.
It turned out i had to add this line to SessionOptions, or else WinSCP would 'forget' the
users password:
$sessionOptions.AddRawSettings("PasswordPlain", $Password)

What's wrong with SessionOptions.Password?

Sharken wrote:

The way i handled it was to recreate the SessionOptions for a Session-object,
by parsing the Output property and looking for the line starting with 'winscp> open'.
These extracted SessionOptions could then be used for creating a new session object,
which would act exactly as the old session object.
In this case it would have been useful to be able to extract the SessionOptions
from the session object, or some kind of Clone() method on the session object.

Is the absence of Reconnect due to the way WinSCP works ?

Noone asked for reconnect so far.
Why, don't you just reuse your original SessionOptions?

Can I also receive this production version, as I'm also having trouble with this bug.

Hi - I just started using winscp today for a project, and so far I really like it. However, I am running into the exact same issue with this directory problem. Could you please send me the latest beta to my email address on this account so I can continue to develop my project?

Many thanks.

I ran into the same bug, please send development version along with the automation dll if needed

thanks!

-joe

Anonymous wrote:

I ran into the same bug, please send development version along with the automation dll if needed

thanks!

-joe

sorry that was me.. forgot to login.. can you please send me development version for this fix.. thanks

-joe

I have sent the development version to all of you. Also note that 5.2.6 beta with the fix will be likely released tomorrow.

Thanks for emailing it to me - I've been playing with it for a while and it is correctly working now. Many thanks!

The version I tested was: WinSCP, Version 5.2.6 (Build 3732)

martin wrote:

Sharken wrote:

The way i handled it was to recreate the SessionOptions for a Session-object,
by parsing the Output property and looking for the line starting with 'winscp> open'.
These extracted SessionOptions could then be used for creating a new session object,
which would act exactly as the old session object.
In this case it would have been useful to be able to extract the SessionOptions
from the session object, or some kind of Clone() method on the session object.

Is the absence of Reconnect due to the way WinSCP works ?

Noone asked for reconnect so far.
Why, don't you just reuse your original SessionOptions?

Storing the SessionOptions so it can be reused later on would work, but
would also add unneeded complexity to the code. The current method while not
ideal, is still better than storing SessionOptions separately.

Using SessionOptions.Password works fine, but a property of using AddRawSettings
is that the Password is cleared.
See core\SessionData.cpp in the method TSessionData::DoLoad().
This method clears the password, and is called when rawsettings is used.
At least that is the behavior i am experiencing when using the .NET library with PowerShell.

Sharken wrote:

Storing the SessionOptions so it can be reused later on would work, but
would also add unneeded complexity to the code. The current method while not
ideal, is still better than storing SessionOptions separately.

Ok, will consider it.

Using SessionOptions.Password works fine, but a property of using AddRawSettings
is that the Password is cleared.
See core\SessionData.cpp in the method TSessionData::DoLoad().
This method clears the password, and is called when rawsettings is used.
At least that is the behavior i am experiencing when using the .NET library with PowerShell.

That is true, this was fixed in 5.2.6:
https://winscp.net/tracker/1083

martin wrote:

Sharken wrote:

Storing the SessionOptions so it can be reused later on would work, but
would also add unneeded complexity to the code. The current method while not
ideal, is still better than storing SessionOptions separately.

Ok, will consider it.

Request has been added to the tracker:
https://winscp.net/tracker/1088

Is this fixed in WinSCP 5.1.8? Doesn't seem to work on my end.

How do you set the options for disabling 'Cache visited remote directories' and 'Cache directory changes'? I am not seeing an options for that on the $sessionOptions object?

I get the same error, "WinSCP.SessionRemoteException: Real path and requested remote path do not match:" and it appears that it does not like the real path being in all lower case characters where the cached path is all upper case. I was hoping setting the above options would help.

Justx wrote:

How do you set the options for disabling 'Cache visited remote directories' and 'Cache directory changes'? I am not seeing an options for that on the $sessionOptions object?

I get the same error, "WinSCP.SessionRemoteException: Real path and requested remote path do not match:" and it appears that it does not like the real path being in all lower case characters where the cached path is all upper case. I was hoping setting the above options would help.

WinSCP .NET assembly runs by default in isolated environment, so there is no cache loaded at the startup.

I am having the same issue with powershell version 5.9.2.5. I have the connection set as FTP Implicit. I can get-winscpchilditem, but I cannot receive-winscpitem or sync-winscppath.

Thanks!

Theliel wrote:

Hi prikryl.

I'm having problems in the last beta 5.2.5 and FTP access, specifically the error seems that only plays when using explicit TLS encryption.

I can reproduce the issue any time:

a) Log in server
b) transfer some files to or from -> work fine
c) Change remote directory
d) try transfer some file from PC -> server.

Sometimes I need repeat this twice, but finally WinSCP fail:

"Real path and requested remote path do not match: "5120 0 16 test.es 17 test.com" "4096 0 16 test.es 17 test.com"
Copying files from remote side failed."

Once WinSCP show that error, any attempt to read, save, transfer... any file to/from server, result in the same error, so I have to restart winSCP.

Attached a failure session. The only change was replace "realhost" with "test". And yes, my tree structure its something like /test.es/test.com

'Old' version work fine, FileZilla or connection without TLS encryption seems work fine too.

Thank in advanced

Michael King wrote:

I am having the same issue with powershell version 5.9.2.5. I have the connection set as FTP Implicit. I can get-winscpchilditem, but I cannot receive-winscpitem or sync-winscppath.

Please start a new thread and post a complete session log file.