Opened 14 years ago

Closed 11 years ago

Last modified 10 years ago

#5071 closed Patch (outdated)

time/datestamp showing 00 for seconds on all files

Reported by: bendlight Owned by:
Priority: normal Component: FileZilla Client
Keywords: time date timestamp datestamp Cc: ikerrg@…
Component version: Operating system type: Windows
Operating system version: Windows 7 x64


The seconds portion of time/datestamp always displays "00" on all files on our AIX servers. I am using filezilla client version 3.3.01. The date and hour:min are all correct only the seconds are affected. I just noticed this but am sure that this was not the case in the past.

Attachments (3)

snippet_of_remote_frame.png (8.7 KB ) - added by bendlight 14 years ago.
This is a screenshot of the time and dates being display on the remote servers.
filezilla.log (4.1 KB ) - added by bendlight 14 years ago.
FixTicket5071_ZeroSecondsForSFTP.diff (13.7 KB ) - added by Jeremy Braun 13 years ago.
A proposed patch to fix this issue.

Download all attachments as: .zip

Change History (14)

by bendlight, 14 years ago

Attachment: snippet_of_remote_frame.png added

This is a screenshot of the time and dates being display on the remote servers.

comment:1 by Tim Kosse, 14 years ago

Resolution: rejected
Status: newclosed

The server simply doesn't return the seconds in its directory listings, so FileZilla assumes 0.

comment:2 by bendlight, 14 years ago

Well this appears to only be a recent problem and it appears to only affect filezilla as the two other sftp programs used here display the proper seconds.

comment:3 by Tim Kosse, 14 years ago

Please attach a complete log with "Show raw directory listings" enabled in the settings dialog of FileZilla.

by bendlight, 14 years ago

Attachment: filezilla.log added

comment:4 by bendlight, 14 years ago

Well sure enough I don't see any seconds. Thanks for the response. I think I'll have fallback to WINscp as it lists seconds and it is useful to sort on time. I appreciate your time.

comment:5 by Iker, 13 years ago

Cc: ikerrg@… added
Operating system version: Windows xp sp3Windows 7 x64
Priority: normalhigh
Resolution: rejected
Status: closedreopened

I use Filezilla client v3.3.5.1 and the same happens for me. The problem is annoying because I cannot upload the updated files to my SFTP server because Filezilla detects that all the files have been updated (all the files in the server are older than in my computer because they have the seconds in 00). Could you update filezilla's code to avoid checking the full timestamp and read only up to the minutes of a file's modification data?

Thank you.

by Jeremy Braun, 13 years ago

A proposed patch to fix this issue.

comment:6 by Jeremy Braun, 13 years ago

I've attached a patch that remedies this issue. SFTP actually does transfer more attribute details than what the FZ client shows. FZ only parses the text portion of the directory listing, but servers can optionally provide second-resolution UTC timestamps (see section 5 of

fzstp.exe already supported parsing this data, but did not output it to the fz client. I've added new fzstp.exe commands (dir-fz and ls-fz) which output the original directory listing data on one line as before, and then follows that up with whatever binary attributes were supplied in the directory listing.

On the client end, I've added code that parses this (if enabled) in directorylistingparser.cpp. It accepts the mtime as valid, and verifies that the permissions match what was parsed out of the text.

I also fixed a small bug in CToken::GetNumber(hex). 'a'-'f' was computing using (c-'0'+10) instead of (c-'a'+10).

Because these times are already returned in UTC, I added a new timestamp flag in CDirentry to keep track of whether an entry had been timezone-adjusted or not.

Things left to do:

  • The timezone adjustment code wasn't commented much, so I couldn't tell if it was adjusting entry.time to UTC, or to the local timezone of the client. That should be verified by someone more familiar with the code.
  • Error messages and/or handling for mis-matched permissions or the directory bit should be filled in. I'm not sure what the right action was here. Right now, the attribute parsing code bails and discards any results.


comment:7 by Jeremy Braun, 13 years ago

Priority: highnormal
Type: Bug reportPatch

Change property to patch, now that it has a patch attached.

comment:8 by Tim Kosse, 13 years ago

Status: reopenedmoreinfo_reopened

Thank you for your path. Unfortunately I think this is a far too complicated solution, especially the splitting up into multiple lines.

Instead, you should probably re-use an existing, well standardized listing format for this purpose. I'm thinking of totally ignoring the human readable part of the SFTP listing entry and converting the machine parsable parts of it into a new human readable string using the syntax of FTP's MLSD listing format.

comment:9 by Jeremy Braun, 13 years ago

Status: moreinfo_reopenedreopened

No problem, that's a much better idea. I'll take a look and see what existing formats include second and timezone information, and come back with an alternative when it's ready. Thank you for the suggestion.

comment:10 by Tim Kosse, 12 years ago

Status: reopenedmoreinfo_reopened

comment:11 by Alexander Schuch, 11 years ago

Resolution: outdated
Status: moreinfo_reopenedclosed

As there is no updated yet, I am closing this as "outdated". Feel free to re-open this once the new version of the patch is done. Thank you.

Note: See TracTickets for help on using tickets.