| Summary: | remote ls -l <name> produces inconsistent info | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | DOUGLAS MCILROY <doug> | ||||
| Component: | sftp | Assignee: | Damien Miller <djm> | ||||
| Status: | CLOSED FIXED | ||||||
| Severity: | normal | CC: | djm, dtucker | ||||
| Priority: | P5 | ||||||
| Version: | 7.5p1 | ||||||
| Hardware: | ix86 | ||||||
| OS: | Linux | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 2698 | ||||||
| Attachments: |
|
||||||
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). 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.
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.
patch applied. This will be in OpenSSH 7.6 Close all resolved bugs after release of OpenSSH 7.7. |
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