Unable to copy files from network drive - "xxxxxx\is not a file!"

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.

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.

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.

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

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.

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.

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.

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.