Windows version: Windows 10 Enterprise 20H2
Transfer protocol: FTP
When I first started trying to use WinSCP to access a z/OS FTP server (MVS side), I was getting baffling results. At first it seemed to work, but when I tried the same server again later, I couldn't get it to read directories. It kept saying "No such file or directory" even for directories that existed. The same command sequence that worked the first time would fail the second time.
If I switched to a different server name, it would work at first but then start failing again. And, it would work if I tried it with completely different directories, at first, but then they too would be become poisoned.
I finally realized that if I manually deleted the registry entries where WinSCP was caching directories, the problem would be fixed, temporarily.
Attached is a log of an attempt to recreate this issue. I'm trying a number of things until I finally figured it out, including switching from the MVS side to the z/OS Unix side.
What I think the problem is this:
- The first time you enter a CD command, it issues the CWD command exactly as the user enters it. This works.
- If WinSCP has cached the directory, then when you later enter the same CD command, WinSCP doesn't do the CWD as the user entered it. Instead, it submits it Unix-style, with a preceding slash. This is not valid syntax, so it fails.
- And then it might be caching that it failed. I'm not sure about that part.
If you enter the directory unquoted, it means that it is appended to the current working directory, i.e. it goes down one level.
If you enter the directory quoted, then it means that it overrides the current working directory. On a Unix system it would be equivalent to entering /directory.
In the log, my working directory always starts as TTPJMSS. There also exists a data set PECML.I1R00.LANLOAD.D220320, so I can navigate down that path: start at 'PECML', then cd I1R00, cd LANLOAD, etc.
In the log this works at first. But notice what happened at the end of the log: I entered cd 'pecml', but the command generated was CWD /'PECML.'. This is not valid on the MVS side.
Note: When I talk about MVS vs Unix side, I'm being inaccurate. Really it is that there are two file systems on the server, with different naming syntax. So I can connect with FTP to the z/OS system, and access an MVS data set PECML.I1R00.LANLOAD, but also access in the same session a Unix directory /u/ttpjmss. In the log when I FTP to the server it sets the working directory to the MVS data set node TTPJMSS, but when I don't enter the protocol then it defaults the working directory to /u/ttpjmss.
The point here is that you can't mix and match the syntax. A file in the Unix file system is a strict Unix style naming, e.g. /dir1/dir2/etc. A file in the MVS file system will never have a /, that's not a valid character in the directory & file names.
So what needs to be cached and re-entered as commands is how the server returns back the PWD results. A result like
257 "'PECML.I1R00.LANLOAD.'" is working directory.