Files are being treated as folders

Got a really weird issue with one specific server. When I double-click on a document, WinSCP thinks it is a folder and attempts to open it as such...but also displays an error message:

Unable to open directory
-----
No such file or directory.
Error code: 2
Error message from server: None
Request code: 11
-----

To edit files, I have to right-click on the file and select the Edit option from the dropdown. This behavior only occurs on this particular server. All the other servers I connect to I can just double-click on files and they will open up in the text editor.


WinSCP v4.0.5 Build 354

Session protocol = SSH-2
SSH implementation = Sun_SSH_1.0
Encryption algorithm = aes
Compression = No
File transfer protocol = SFTP-2
Can change permissions = Yes
Can change owner/group = No
Can execute arbitrary command = No
Can create symlink/hardlink = No/No
Can lookup user groups = No
Can duplicate remote files = No
Can check available space = No
Can calculate file checksum = No
Native text (ASCII) mode transfers = No
------------------------------------------------------------
Additional information
The server does not support any SFTP extension.


Norton Commander interface.


<Trimmed sensitive information>
. 2007-11-30 10:03:32.636 Using SFTP protocol.
. 2007-11-30 10:03:32.636 Doing startup conversation with host.
> 2007-11-30 10:03:32.636 Type: SSH_FXP_INIT, Size: 5, Number: -1
< 2007-11-30 10:03:32.652 Type: SSH_FXP_VERSION, Size: 5, Number: -1
. 2007-11-30 10:03:32.652 SFTP version 2 negotiated.
. 2007-11-30 10:03:32.652 We believe the server has signed timestamps bug
. 2007-11-30 10:03:32.652 We will use UTF-8 strings for status messages only
. 2007-11-30 10:03:32.652 Changing directory to "/usr/local/apache/htdocs".
. 2007-11-30 10:03:32.652 Getting real path for '/usr/local/apache/htdocs'
> 2007-11-30 10:03:32.652 Type: SSH_FXP_REALPATH, Size: 33, Number: 801808
< 2007-11-30 10:03:32.652 Type: SSH_FXP_NAME, Size: 69, Number: 801808
. 2007-11-30 10:03:32.652 Real path is '/usr/local/apache/htdocs'
. 2007-11-30 10:03:32.652 Trying to open directory "/usr/local/apache/htdocs".
> 2007-11-30 10:03:32.652 Type: SSH_FXP_LSTAT, Size: 33, Number: 802055
< 2007-11-30 10:03:32.652 Type: SSH_FXP_ATTRS, Size: 37, Number: 802055
. 2007-11-30 10:03:32.652 Getting current directory name.
. 2007-11-30 10:03:32.652 Listing directory "/usr/local/apache/htdocs".
> 2007-11-30 10:03:32.652 Type: SSH_FXP_OPENDIR, Size: 33, Number: 802315
< 2007-11-30 10:03:32.667 Type: SSH_FXP_HANDLE, Size: 13, Number: 802315
> 2007-11-30 10:03:32.667 Type: SSH_FXP_READDIR, Size: 13, Number: 802572
< 2007-11-30 10:03:32.667 Type: SSH_FXP_NAME, Size: 3999, Number: 802572
> 2007-11-30 10:03:32.667 Type: SSH_FXP_READDIR, Size: 13, Number: 802828
< 2007-11-30 10:03:32.667 Type: SSH_FXP_STATUS, Size: 9, Number: 802828
< 2007-11-30 10:03:32.667 Status/error code: 1
> 2007-11-30 10:03:32.667 Type: SSH_FXP_CLOSE, Size: 13, Number: 803076
. 2007-11-30 10:03:32.667 Startup conversation with host finished.
. 2007-11-30 10:03:37.418 Changing directory to "test.php".
. 2007-11-30 10:03:37.418 Getting real path for '/usr/local/apache/htdocs/test.php'
> 2007-11-30 10:03:37.418 Type: SSH_FXP_REALPATH, Size: 42, Number: 803344
< 2007-11-30 10:03:37.418 Type: SSH_FXP_STATUS, Size: 9, Number: 803076
. 2007-11-30 10:03:37.418 Discarding reserved response
< 2007-11-30 10:03:37.418 Type: SSH_FXP_NAME, Size: 87, Number: 803344
. 2007-11-30 10:03:37.418 Real path is '/usr/local/apache/htdocs/test.php'
. 2007-11-30 10:03:37.418 Trying to open directory "/usr/local/apache/htdocs/test.php".
> 2007-11-30 10:03:37.418 Type: SSH_FXP_LSTAT, Size: 42, Number: 803591
< 2007-11-30 10:03:37.433 Type: SSH_FXP_ATTRS, Size: 37, Number: 803591
. 2007-11-30 10:03:37.433 Getting current directory name.
. 2007-11-30 10:03:37.433 Listing directory "/usr/local/apache/htdocs/test.php".
> 2007-11-30 10:03:37.433 Type: SSH_FXP_OPENDIR, Size: 42, Number: 803851
< 2007-11-30 10:03:37.433 Type: SSH_FXP_STATUS, Size: 9, Number: 803851
< 2007-11-30 10:03:37.433 Status/error code: 2, Message: 803851, Server: None, Language:
* 2007-11-30 10:03:37.433 (ECommand) Error listing directory '/usr/local/apache/htdocs/test.php'.
* 2007-11-30 10:03:37.433 No such file or directory.
* 2007-11-30 10:03:37.433 Error code: 2
* 2007-11-30 10:03:37.433 Error message from server: None
* 2007-11-30 10:03:37.433 Request code: 11
. 2007-11-30 10:03:47.808 Closing connection.

With SFTP version 2 and below, WinSCP has no way to find out if file is plain file or symbolic link (possibly pointing to a directory). Hence WinSCP always treats a file as symbolic link to allow you to "enter" them (in case it points to directory). SFTP version 2 and older is quite rare these days. Personally, I have never seen a such a server yet :-)

WinSCP has no way to find out if file is plain file or symbolic link (possibly pointing to a directory). Hence WinSCP always treats a file as symbolic link to allow you to "enter" them (in case it points to directory).

Sure it does: It generates an error message as documented above stating that it isn't a directory.

So, WinSCP should attempt to open it as a directory as it currently does. If it fails to do that, attempt to open it as a file. If all that fails, THEN display an error message.

samiham wrote:

So, WinSCP should attempt to open it as a directory as it currently does. If it fails to do that, attempt to open it as a file. If all that fails, THEN display an error message.

It does not make sense to try to open something again in another mode, if the server reports "No such file or directory".

martin wrote:

samiham wrote:

So, WinSCP should attempt to open it as a directory as it currently does. If it fails to do that, attempt to open it as a file. If all that fails, THEN display an error message.

It does not make sense to try to open something again in another mode, if the server reports "No such file or directory".

The only problem is that every last file on a SFTP2 server is treated like a directory. Windows itself attempts to do things multiple times in different modes. For usability purposes, when a failure condition can potentially be averted by trying something else (no matter how stupid attempting that something else is), such code should be written. Only when all options are exhausted should an error message be propagated back up to the end-user.