Giacomo TesioFurther down this rabbit hole.<br>Sorry for the noise, but the more I go deeper, the worse it looks like, and I need to vent to people who might understand.<br><br>The <a href="https://snac.tesio.it?t=sftp" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SFTP</a> <a href="https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-02#section-7" rel="nofollow noopener noreferrer" target="_blank">specification version 3, section 7</a> actually provides the number of links of each file the "longname" of the SSH_FXP_NAME response:<br><br><pre>The SSH_FXP_NAME response has the following format:<br><br> uint32 id<br> uint32 count<br> repeats count times:<br> string filename<br> string longname<br> ATTRS attrs<br>[...]<br>`longname' is an expanded format for the file name, similar to what<br>is returned by "ls -l" on Unix systems<br>[...]<br>The format of the `longname' field is unspecified by this protocol.<br>It MUST be suitable for use in the output of a directory listing<br>command (in fact, the recommended operation for a directory listing<br>command is to simply display this data).<br></pre>So far so good: we should have the info we need (at least from unix servers) despite in an unfortunate textual format.<br><br>The specification also states that such long name MUST not be parsed and clients should rely on the binary attributes that follow, except that the same specification forgot to include st_nlink (maybe because not all operating system supports such info).<br><br>However let assume that we ignore that argument and patch sshfs to read and parse such text just to provide the proper st_nlink.<br><br>Will <a href="https://snac.tesio.it?t=openssh" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#OpenSSH</a> properly implement the specification?<br><br>NO! It doesn't! 😭<br><br>Let's give it a try:<br><br><pre>sftp> cd test<br>sftp> ls -l<br>-rw-r--r-- 2 tesio users 0 Mar 26 20:34 copy<br>-rw-r--r-- 2 tesio users 0 Mar 26 20:34 file<br>sftp> ls -l *<br>-rw-r--r-- ? 115209 100 0 Mar 26 21:34 copy<br>-rw-r--r-- ? 115209 100 0 Mar 26 21:34 file<br></pre>It turns out that the sftp-server from OpenSSH handles <code>ls -l</code> differently when it is received <a href="https://github.com/openssh/openssh-portable/blob/master/sftp.c#L1673-L1676" rel="nofollow noopener noreferrer" target="_blank">without any argument</a> or <a href="https://github.com/openssh/openssh-portable/blob/master/sftp.c#L1679-L1684" rel="nofollow noopener noreferrer" target="_blank">with an argument</a>.<br><br>In the first case (no argument) the request comply to the specification.<br>In the second, it does not, apparently for no reason (the <code>ls_file</code> function <a href="https://github.com/openssh/openssh-portable/blob/master/sftp-common.c#L216-L241" rel="nofollow noopener noreferrer" target="_blank">receives remote = 1</a>).<br><br>So to properly fill <code>st_nlink</code> in <a href="https://snac.tesio.it?t=sshfs" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#sshfs</a>, for any file we should sent an additional SSH_FXP_READDIR request to the server <b>for the parent directory</b>, find our file of interest within the list of files and extract the number of links from its longname.<br><br>And we are talking about OpenSSH!<br><br>Guys... I wanna cry.<br><br>CC: <span class="h-card"><a href="https://fedi.dreamscape.link/rozenglass" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@rozenglass@fedi.dreamscape.link</a></span> <span class="h-card"><a href="https://comam.es/snac/grunfink" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@grunfink@comam.es</a></span> <span class="h-card"><a href="https://hj.9fs.net/khm" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@khm@hj.9fs.net</a></span> <span class="h-card"><a href="https://labyrinth.zone/users/Velveteen" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@Velveteen@labyrinth.zone</a></span><br>