When I do an ls -ltr with no arguments I get a listing for a file saying something like sftp> ls -ltr : -rw-rw-rw- 1 user group 10466 May 14 20:42 P1.XXXX : However when I list the file explicitly sftp> ls -ltr P1.XXXXX -rw-rw-rw- 0 0 0 10466 May 14 15:42 P1.XXXXX sftp> ls -l P1.XXXXX -rw-rw-rw- 0 0 0 10466 May 14 15:42 P1.XXXXX The SFTP Server and Client are both in CDT timezone though the TZ environment variable isn't set and the 20:42 is obviously the UT time
reproduced with 6.2p2. also the uid->name lookups and link counts are broken in the second example.
Created attachment 2312 [details] call tzset() for sftp-server and before chroot in sshd The difference between "ls -ltr" and "ls -ltr FILENAME" is that the first uses the longname from the server and the second synthesises the line on the client. uid->name and link counts aren't supported by our dialect of the sftp protocol. They are only listed in the "longname" element in the sftp dirent struct, so they are expected to be wrong in the locally-generated version. The time shouldn't be wrong though - the server generates the longname's time using localtime() and strftime(). Perhaps it needs a tzset() first? Someone has reported a similar problem a while ago on for chrooted sftp and IIRC a similar patch to this helped.
Retarget to openssh-6.4
Retarget 6.3 -> 6.4
btw, I'm not going to apply this patch until someone reports that it solves their problems.
Retarget incomplete bugs / feature requests to 6.6 release
Retarget to 6.7 release, since 6.6 was mostly bugfixing.
Remove from 6.6 tracking bug
remove target until someone who can replicate this tests the fine patch.
No followup for 5 years == no bug
Closing all resolved bug with release of openssh-8.2