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.

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

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.

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.

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

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

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:

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.

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)

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.

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 ran into the same bug, please send development version along with the automation dll if needed

thanks!

-joe

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.

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

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?

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?

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 ?

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.

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.

Theliel wrote:

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

Thanks for your feedback.

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.

Hi prikryl, seen work fine :).

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

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.

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.

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