"SHOULD NOT attempt to parse the longname field

[ian@brackenbury.nz]

I asked the developer of greenend-sftp a server running on a large number of Humax media boxes,
why we see large file sizes truncated, leading us to believe the up/download has failed until
we use Telnet to check the sizes on the Humax.

I said:

The file size shown for large files have the right digits but are out by factor of - in the cases I've looked at - 10 or 100.
eg, ls -al gives 739159296, the SFTP client (Filezilla and Transmit) gives 73.9MB
ls -al gives 1365402224, the SFTP client eg Transmit gives 13.7MB

Same clients accessing other sites using FTP get the right answer.
I've set up SFTP on my Austor NAS and transferred a large file there, again the size numbers are right.

It is as if the SFTP clients ask for a directory listing from Greenend-sftp and for large files the number is incorrect, or greenend-ftp is using some convention that our sftp clients don't recognise?

It's hardly "mission critical" but is this a known bug, or "working as designed" or due to something other than greenend-sftp on dropbear?

and the author replied: (see last line in particular)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On SourceForge ewxrjk commented:
The format of the `longname' field is unspecified by this protocol.
It MUST be suitable for use in the output of a directory listing
command (in fact, the recommended operation for a directory listing
command is to simply display this data). However, clients SHOULD NOT
attempt to parse the longname field for file attributes; they SHOULD
use the attrs field instead.

The recommended format for the longname field is as follows:

-rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer
1234567890 123 12345678 12345678 12345678 123456789012

Here, the first line is sample output, and the second field indicates
widths of the various fields. Fields are separated by spaces. The
first field lists file permissions for user, group, and others; the
second field is link count; the third field is the name of the user
who owns the file; the fourth field is the name of the group that
owns the file; the fifth field is the size of the file in bytes; the
sixth field (which actually may contain spaces, but is fixed to 12
characters) is the file modification time, and the seventh field is
the file name. Each field is specified to be a minimum of certain
number of character positions (indicated by the second line above),
but may also be longer if the data does not fit in the specified
length.
The SFTP server is truncating the size field to 8 digits despite the freedom given to extend it. Pedantically this isn't a bug since the spec does not constrain the content of the 'longname' field, but the current outcome is perverse.

But it's also a bug in FileZilla, which is ignoring the "SHOULD NOT attempt to parse the longname field".

[botg]

SHOULD NOT is not a MUST NOT. In the case of SHOULD NOT there may be valid reasons to deviate from the requirement.

In the case of FileZilla, there is already machinery to parse human-readable directory listings in a plethora of formats. It was easier to simply parse longname than to extract attrs.

The bug here is solely with the server. It hands out wrong data.