Fascinating. Good to see it fixed :)

I'm surprised that helped, however, as WinSCP for me automatically edits that to something that works. I suppose there's some difference.

I was testing with a different server - can't remember what it was using now without looking at the logs (something on Linux). Might be how the server's handle it that causes WinSCP to change it. Not like I'm looking at source code here so. Is is fascinating.

IT'S FIXED!!!!!!

Checked the users remote directory path and sure enough somehow /.. had been inserted before the /Foldername.
Removed the /.. and it worked fine.
No idea why the heck it was there but as per your responses it would appear FileZilla needs updating (which is in process as we speak)
HUGE thanks to all of you for your help with this one.

One last thing from me. With SFTP, I can get /../ to happen in the log (Remote directory: /../foo/ or /foo/../foo/) by manually editing the remote dir advanced setting and switching it in. WinSCP then complains about that, adjusts, and everything continues to work. After this, files still transfer fine and the file path is listed fine in WinSCP.

If it was WinSCP, I don't see how.

Thanks all, i've been through your posts, found the article that mentions a) the age of the client we're using and b) that specific issue where it inserts /../ into the filepath
I'm going to raise a change ticket now to update the FileZilla client on our servers and hopefully this will fix the issue.
It'll take about 2 weeks though but I'll post again here with the result.
Thanks all and speak soon.

Nevermind that one was FTP lol. But, still the version is over 2 years old.

Should also add

So, the user here is using a version without the fixed ./ bug. The user should fully update the server if possible. The ./ bug is fixed in 1.8.1 (2024-01-26).

There's be more path fixes since 1.5.3 (2022-08-11).

There was definitely this:

FTP Server: NLST would report a file names with a leading ./ path in certain cases, which confused some clients. Fixed.

https://filezillapro.com/filezilla-pro-enterprise-server-version-history/

I don't know what WinSCP code would think about a ./ and if it would somehow translate that as ../.

But, it's difficult to know and complicated. The server has a lot of power here to cause problems.

My guess is that it's likely a combination of some bug on the server that leads to the /../ path and WinSCP getting confused by the leading /...

Isn't FileZilla server including .. even in the root directory? That's common, and not a problem on its own. But it can become a problem, if the server claims that the .. really represents a nonexisting /../ path, while major servers resolve .. in root back to root – /. For example, in Linux:

---

Some suggestions to get rid of the problem:

• Clear the remembered directory from https://winscp.net/eng/docs/ui_login_directories
  
• Clear caches: Commands > Clear Caches
  
• Login again
  
• Don't try to go to /.. (if my above assumption is correct)
  

Hmmm. The client here gets the files listed in the dir fine so I wouldn't be convinced the ../ has anything to do with this. As its perfectly fine getting the files listed here. And the only thing that's next is to select one to transfer and do it. That says that both sides are correctly on the same path there.

(You can also see the server logs and what its receiving from the client and sending back to confirm which side is causing the problem.)

At least from what I see in your WinSCP logs...

This has to be from the server as it has file date and size present. The client cannot know that without the server providing it. So, that's the wrong path returned by the server. The server should not be returning a file path of /. That's devoid of a file.

So, based on this lacking info, at least to me these logs only show a path issue in FileZilla Server Pro Enterprise Server, of which has had path bugs fixed it its changelog so its a reoccurring issue there.

Either way, the only other alternative should be WinSCP mangling the path assuming that the log entry "File: '/' [2024-08-01T13:51:59.000Z] [41078680]" was a WinSCP hacked together string for logging and not directly what the server returned.

I didn't look at the WinSCP code for this but I heavily lean towards a server issue here. Considering, I worked for hundred of hours on server code myself in recent years.

Don't know if that will help or not, but I'm hoping it does :)

Hi Martin, the user connects to the remote folder by connecting to our FTP site using the full FQDN ftp-iet.theiet.org and her login credentials. We use FileZilla to provide the FTP site
Her account on FileZilla is exactly the same as other colleagues who don't have this issue
I see your point about the ../ appearing in the remote file path
I'll do some checking again of her account and WinSCP client setup and see if anything comes up.

How did you get to be in /../Livefeeds/ASME on the remote panel? That might be the problem.

In your first log, I've assumed that you have masked some sensitive information with ... But now it seems that it is the "actual" path. While in your original "success" log, the actual path seems to be correct /Livefeeds/ASME.

It took a while but I've attached a full log file from an attempt earlier today by the user to copy files from our FTP site onto our network drive
I've taken another look at it and everything appears normal until line 307 where I'd expect the full filepath of the source file to be shown but instead only a / is shown
Then 4 lines later the error message appears stating that

Z:\data_management\To process\ASME\INSPEC2 Journals\' is not file! ()

Z:\xxxx being a shared folder on one of our servers.
The User states they highlighted the file in question and tried to drag it to the source-folder pane.
To re-cap, WinSCP is installed using a script and the same installation has been used on other Users' machines and they don't have this problem
Screenshots are on their way.

Ok, so please post the screenshots and (complete!) logs once possible. Thanks.

Hi Martin, the user is off on leave now for a week and I'm away for the week after so I can't get any 'live' data at this point.
However, when I was performing troubleshooting the user wasn't doing anything differently than I was. Either drag and dropping the file from the source-pane to the destination-pane or by using the right-click 'Move to' option.
I've performed a new transfer on my laptop today and attached the relevant portion of the log file as requested.

How does the user initiate the file transfer? Can you post few screenshots documenting that?
And screenshots from your computer and your log file for comparison.

Client version is WinSCP Version 6.3.4
OS is Windows 10
Connection protocol SFTP
Trying to copy files from a server to a network share but when the user tries they get an error pop up stating the destination path is not a file:

Debugging was enabled, I've read through the log file and it appears to identify the source file(s) and size correctly but when it lists the destination it only shows a / instead of the file path and the error appears in the next few lines
User permissions for source and destination have been checked and rechecked, client has been reinstalled, settings compared with others that work
User tried with another laptop and it worked, briefly, but the same issue occurred after a day
I compared the log file from WinSCP with my own when I perform the same operation and I'm pretty sure that mine shows the full destination filepath instead of /.
A little stumped on this to say the least.
User is able to use another file-transfer application for now but we prefer WinSCP.