Wrong timestamp in Filezilla as FTP Client

[SERGIO]

The timestamp bug is still when you trie to move files from last version of Filezilla (as FTP client) to a SFTP server (in this case Tectia).

Windows 7 64 bits

Could you provide to me further details to solve this issue?

Thanks

[Tim Kosse]

Which timestamp bug are you referring to?

[SERGIO]

filezilla_wrong_timestamp

[SERGIO]

Please, view attachments. I have attached a screenshot.

[Tim Kosse]

The timestamp bug is still when you trie to move files [...]

For reference, could you please link to the original bug report?

[SERGIO]

Replying to codesquid:

The timestamp bug is still when you trie to move files [...]

For reference, could you please link to the original bug report?

Hi, I copy the command list:

08:54:24 Status: Connecting to localhost...
08:54:24 Trace: Going to execute "C:\Program Files (x86)\FileZilla FTP Client\fzsftp.exe"
08:54:24 Response: fzSftp started
08:54:24 Trace: CSftpControlSocket::ConnectParseResponse(fzSftp started)
08:54:24 Trace: CSftpControlSocket::SendNextCommand()
08:54:24 Trace: CSftpControlSocket::ConnectSend()
08:54:24 Command: open "NG55CC6@localhost" 22
08:54:24 Trace: Looking up host "localhost"
08:54:24 Trace: Connecting to ::1 port 22
08:54:24 Trace: Server version: SSH-2.0-6.4.6.215 SSH Tectia Server
08:54:24 Trace: Using SSH protocol version 2
08:54:24 Trace: We claim version: SSH-2.0-PuTTY_Local:_Aug__7_2013_21:25:06
08:54:24 Trace: Using Diffie-Hellman with standard group "group14"
08:54:24 Trace: Doing Diffie-Hellman key exchange with hash SHA-1
08:54:24 Trace: Host key fingerprint is:
08:54:24 Trace: ssh-rsa 1536 a5:cf:36:90:d1:b8:c3:c0:d5:15:6d:be:77:d7:4d:99
08:54:24 Trace: Initialised AES-256 SDCTR client->server encryption
08:54:24 Trace: Initialised HMAC-SHA1 client->server MAC algorithm
08:54:24 Trace: Initialised AES-256 SDCTR server->client encryption
08:54:24 Trace: Initialised HMAC-SHA1 server->client MAC algorithm
08:54:24 Command: Pass:
08:54:24 Trace: Sent password
08:54:25 Trace: Access granted
08:54:25 Trace: Opened channel for session
08:54:25 Trace: Started a shell/command
08:54:25 Status: Connected to BLLX300092582.tls.fr.eu.airbus.corp
08:54:25 Trace: CSftpControlSocket::ConnectParseResponse()
08:54:25 Trace: CSftpControlSocket::ResetOperation(0)
08:54:25 Trace: CControlSocket::ResetOperation(0)
08:54:25 Trace: CSftpControlSocket::FileTransfer(...)
08:54:25 Status: Starting upload of C:\Users\NG55CC6\Desktop\SFPT_TEST.txt
08:54:25 Trace: CSftpControlSocket::SendNextCommand()
08:54:25 Trace: CSftpControlSocket::ChangeDirSend()
08:54:25 Command: cd "/TEST"
08:54:25 Response: New directory is: "/TEST"
08:54:25 Trace: CSftpControlSocket::ResetOperation(0)
08:54:25 Trace: CControlSocket::ResetOperation(0)
08:54:25 Trace: CSftpControlSocket::ParseSubcommandResult(0)
08:54:25 Trace: CSftpControlSocket::FileTransferSubcommandResult()
08:54:25 Trace: CSftpControlSocket::SendNextCommand()
08:54:25 Trace: FileTransferSend()
08:54:25 Command: put "C:\Users\NG55CC6\Desktop\SFPT_TEST.txt" "SFPT_TEST.txt"
08:54:25 Status: local:C:\Users\NG55CC6\Desktop\SFPT_TEST.txt => remote:/TEST/SFPT_TEST.txt
08:54:25 Trace: FileTransferParseResponse()
08:54:25 Trace: CSftpControlSocket::ResetOperation(0)
08:54:25 Trace: CControlSocket::ResetOperation(0)
08:54:25 Status: File transfer successful, transferred 14 bytes in 1 second
08:54:25 Status: Retrieving directory listing...
08:54:25 Trace: CSftpControlSocket::ParseSubcommandResult(0)
08:54:25 Trace: CSftpControlSocket::ListSubcommandResult()
08:54:25 Trace: CSftpControlSocket::SendNextCommand()
08:54:25 Trace: CSftpControlSocket::ListSend()
08:54:25 Command: ls
08:54:25 Status: Listing directory /TEST
08:54:25 Listing: drwx------ 1 0 0 0 Dec 9 8:54 ./
08:54:25 Listing: drwx------ 1 0 0 0 Jan 1 0:00 ../
08:54:25 Listing: -rw------- 1 0 0 14 Dec 9 8:54 SFPT_TEST.txt
08:54:25 Trace: CSftpControlSocket::ListParseResponse()
08:54:25 Trace: CSftpControlSocket::ResetOperation(0)
08:54:25 Trace: CControlSocket::ResetOperation(0)
08:54:25 Status: Directory listing successful

[Tim Kosse]

You mentioned that the bug still has not been fixed. This means that it must have already been reported before. Where is this earlier bug report you are referring to? I need the ticket number, forum post or email timestamp of the original report.

[SERGIO]

No, this is the first ticket number that I have opened. Its ticket number is #11100 moreinfo (Bug report)

[SERGIO]

Have you investigate anything about this bug?
Thanks

[Tim Kosse]

Sounds similar to ​https://forum.filezilla-project.org/viewtopic.php?t=26478, which would make it a server bug.
FileZilla obtains the timestamps for files via the same mechanism as the mtime directive as seen in the linked topic. The human-readable timestamp in the log is ignored as it lacks the information of the machine-readable timestamps.

If the server sends the wrong machine-readable timestamps then subsequently these wrong timestamps are correctly displayed by FileZilla.

Please update your server to the most recent version of the Tectia Server. If the problem persists, contact your server vendor for further assistance.

[SERGIO]

Ok, thanks for the information and the link.
I understand now the problem. However, I have tested the SFTP connection with other application (in this case, MobaXterm). Using MobaXterm as SFTP Client, the modified dates are showed correctly while Filezilla shows them incorrectly. For this reason, I could think that the problem is not in Server (Tectia) side.

Regards

[Tim Kosse]

The SSH_FXP_NAME package of SFTP contains up to two modification times:

• A human-readable description of the file intended for humans that may contain a modification time, with the format of this human-readable output unspecified
• Machine-readable metadata including the last modification time in seconds since 1970-01-01 00:00:00

Contrary to the intention of this data some clients parse the human-readable data instead of using the machine-readable data.

What does MobaXterm do? Does it print or parse the human-readable description or does it actually base the information it displays on the machine-readable data?

[SERGIO]

I am not an expert in SFTP, so I do not know what MobaXterm does...
All I know is that the modified date is showed correctly in MobaXterm, but it is showed incorrectly in Filezilla. For this reason, I think that the problem is not in SFTP Server (Tectia) side.

Any suggestion about how to solve this issue in Filezilla?

[Tim Kosse]

You're making the assumption that both FileZilla and MobaXterm parse the machine-readable timestamp. This assumption may not be true.

It is more likely that the server sends mismatching human- and machine-readable timestamps.