Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#11100 closed Bug report (rejected)

Wrong timestamp in Filezilla as FTP Client

Reported by: SERGIO Owned by:
Priority: high Component: FileZilla Client
Keywords: wrong timestamp filezilla client Cc:
Component version: FileZilla Client Operating system type: Windows
Operating system version: windows 7

Description

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

Attachments (1)

FILEZILLA1.jpg (141.0 KB ) - added by SERGIO 8 years ago.
filezilla_wrong_timestamp

Download all attachments as: .zip

Change History (13)

comment:1 by Tim Kosse, 8 years ago

Status: newmoreinfo

Which timestamp bug are you referring to?

by SERGIO, 8 years ago

Attachment: FILEZILLA1.jpg added

filezilla_wrong_timestamp

comment:2 by SERGIO, 8 years ago

Status: moreinfonew

Please, view attachments. I have attached a screenshot.

comment:3 by Tim Kosse, 8 years ago

Status: newmoreinfo

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

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

in reply to:  3 comment:4 by SERGIO, 8 years ago

Status: moreinfonew

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

comment:5 by Tim Kosse, 8 years ago

Status: newmoreinfo

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.

comment:6 by SERGIO, 8 years ago

Status: moreinfonew

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

comment:7 by SERGIO, 8 years ago

Have you investigate anything about this bug?
Thanks

comment:8 by Tim Kosse, 8 years ago

Resolution: rejected
Status: newclosed

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.

comment:9 by SERGIO, 8 years ago

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

comment:10 by Tim Kosse, 8 years ago

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?

comment:11 by SERGIO, 8 years ago

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?

comment:12 by Tim Kosse, 8 years ago

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.

Note: See TracTickets for help on using tickets.