Bug 2710 - remote ls -l <name> produces inconsistent info
Summary: remote ls -l <name> produces inconsistent info
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sftp (show other bugs)
Version: 7.5p1
Hardware: ix86 Linux
: P5 normal
Assignee: Damien Miller
URL:
Keywords:
Depends on:
Blocks: V_7_6
  Show dependency treegraph
 
Reported: 2017-04-25 00:46 AEST by DOUGLAS MCILROY
Modified: 2018-04-06 12:26 AEST (History)
2 users (show)

See Also:


Attachments
Replace link count with '?' when unavailable (1.77 KB, patch)
2017-06-02 15:59 AEST, Damien Miller
dtucker: ok+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description DOUGLAS MCILROY 2017-04-25 00:46:44 AEST
Remote ls -l produces different information for the same files depending on whether or not a file argument (including wildcards) is present. With a file argument, the link count is 0 and user and group are given by number. Without an argument, link count is correct and user and group are given by name.

The OS's where I have observed this are local=cygwin64 or Linux and
remote=Linux. I haven't tried any others.

To observe the behavior make an sftp connection, then execute commands
    ls -l
    ls -l *

I do not know the versions of sftp, since the command does not seem to support a version inquiry. However the versions of ssh are
OpenSSH_7.4p1, OpenSSL 1.0.2j  26 Sep 2016      on cygwin64
OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015   on Linux
Comment 1 Damien Miller 2017-04-28 13:44:48 AEST
This is unfortunate, but expected.

When doing plain 'ls -l', the sftp-client uses the "longname" listing that is generated by the server since it often provides information that is otherwise unavailable through the sftp protocol (e.g. user/group names).

When doing a globbed ls, e.g. "ls -l *', sftp generates the listing at the client side from the sftp equivalent of stat() operations on the files.

We might implement a protocol extension to get user/group names from the remote end, then we could use the latter path for consistency always (for servers that support the extension anyway).
Comment 2 DOUGLAS MCILROY 2017-04-29 07:25:02 AEST
It is more than unfortunate. It gives misinformation: link count 0. One can learn by experiment that this is a quirk, but one's first impression is that something has gone wrong. While a change in protocol probably is the best fix, the bug could be ameliorated by either of the following client-side methods:

1. Always perform ls -l as if it had no arguments, then display only the requested entries. This gives fully familiar output at extra cost in
server-side processing and data transmission. It probably entails a net reduction in code.

2. Display link count as a nonnumeric indicator, e.g. one of {- _ ?}.
This eliminates the worst misunderstanding, but still gives surprising, although correct, uid and gid. It costs nothing.
Comment 3 Damien Miller 2017-06-02 15:59:32 AEST
Created attachment 2989 [details]
Replace link count with '?' when unavailable

I, and most people I've asked, prefer the user/group names to uid/gid, so I think making sftp do the equivalent to "ls -l" would be a negative change.

This patch replaces the link count for the locally-synthesised file list with '?' when it is unavailable.
Comment 4 Damien Miller 2017-06-10 16:41:13 AEST
patch applied. This will be in OpenSSH 7.6
Comment 5 Damien Miller 2018-04-06 12:26:39 AEST
Close all resolved bugs after release of OpenSSH 7.7.