My current workaround is to disable the option to remember the last used directory, and set the default/home directory to /dev_ntfs0:/. This then allows normal access to that folder until I click Refresh, which then breaks it. All I need to do in that scenario is click Home and access is restored. Not ideal, but I can work with it until WinSCP, or (highly unlikely) the server is updated.

In addition to what Martin said, servers do have client specific problems as clients don't always do things the same exact way. Paths is one that has client differences that the server has to deal with.

dev_ntfs0 prob can be from a server side issue. It may not even be with paths. It could trip something else.

Still, in WinSCP, sometimes the caches or path lines can cause certain issues. You can test unchecking those and making sure path lines are empty. If those are fine, I agree with Martin that it should be a server issue.

martin wrote:

Imo, the bug is on server-side. WinSCP correctly sends CWD dev_ntfs0: –

> 2026-04-07 17:10:55.976 CWD dev_ntfs0:
< 2026-04-07 17:10:55.976 550 File Error "/dev_ntfs0:"

It seems that the server works correctly only when full path is sent:

> 2026-04-07 17:11:22.660 CWD /dev_ntfs0:
< 2026-04-07 17:11:22.660 250 OK

Are there any options in WinSCP to send the full path by default?

What's also weird is that other folders on the server can be accessed normally, and once dev_ntfs0: is opened once, that can also be opened normally, which is what lead me to believe that the bug is in WinSCP.

Imo, the bug is on server-side. WinSCP correctly sends CWD dev_ntfs0: –

It seems that the server works correctly only when full path is sent:

Hello
There is a folder on my FTP server called dev_ntfs0:. When double clicking on the listing, I get an error: 'File Error "/dev_ntfs0:"'. However, if I use the 'Open directory/bookmark' button, and enter /dev_ntfs0:/, I can access the contents of the folder. Furthermore, this then allows me to access the folder normally, until the server is next restarted. I have tested this same scenario using an FTP client on my mobile, and the issue doesn't occur there, so it seems specific to WinSCP.

I suspect the issue is : in the filename, but this can't be changed, as it is a mount point for an external HDD. Hopefully there's something in the log, and it's an easy fix.