Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

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.
Michael King

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
martin

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.
Justx

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.
raoulwonder

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

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/1088
martin

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/1083
Sharken

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.
Pat

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

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.
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
Guest

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

thanks!

-joe
Pat

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.
Wompus

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

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

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

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 ?
Sharken

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.
martin

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

Theliel wrote:

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

Thanks for your feedback.
Sharken

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

Hi prikryl, seen work fine :).

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

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

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.
daymobrew

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.
Theliel

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