5.2.5 Real path and requested remote path do not match

Advertisement

Theliel
Joined:
Posts:
2

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

Reply with quote

Advertisement

daymobrew
Donor
Joined:
Posts:
8
Location:
Dublin, Ireland

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.

Reply with quote

Sharken
Joined:
Posts:
11

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.

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,227
Location:
Prague, Czechia

Theliel wrote:

I have not managed to fail even much effort I have put into it.
Thanks for your feedback.
_________________
Martin Prikryl

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,227
Location:
Prague, Czechia

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.
_________________
Martin Prikryl

Reply with quote

Sharken
Joined:
Posts:
11

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.

Reply with quote

Sharken
Joined:
Posts:
11

Reconnect()

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 ?

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,227
Location:
Prague, Czechia

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?
_________________
Martin Prikryl

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,227
Location:
Prague, Czechia

Re: Reconnect()

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?
_________________
Martin Prikryl

Reply with quote

Pat
Joined:
Posts:
2

I'm having the same issue

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.

Reply with quote

Guest

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

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,227
Location:
Prague, Czechia

Re: I'm having the same issue

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.

Reply with quote

Pat
Joined:
Posts:
2

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)

Reply with quote

Sharken
Joined:
Posts:
11

Re: Reconnect()

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.

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,227
Location:
Prague, Czechia

Re: Reconnect()

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/show_bug.cgi?id=1083

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,227
Location:
Prague, Czechia

Re: Reconnect()

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/show_bug.cgi?id=1088

Reply with quote

Justx
Guest

setting caching options

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.

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,227
Location:
Prague, Czechia

Re: setting caching options

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.
_________________
Martin Prikryl

Reply with quote

Michael King
Joined:
Posts:
1
Location:
US

Re: 5.2.5 Real path and requested remote path do not match

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

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
27,227
Location:
Prague, Czechia

Re: 5.2.5 Real path and requested remote path do not match

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.

To generate the session log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you can mark the attachment as private.

Reply with quote

Advertisement

You can post new topics in this forum