time/datestamp showing 00 for seconds on all files

[bendlight]

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.

[bendlight]

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

[Tim Kosse]

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

[bendlight]

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.

[Tim Kosse]

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

[bendlight]

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.

[Iker]

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.

[Jeremy Braun]

A proposed patch to fix this issue.

[Jeremy Braun]

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 ​http://filezilla-project.org/specs/draft-ietf-secsh-filexfer-02.txt).

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.

Thanks!
SquiDevil.

[Jeremy Braun]

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

[Tim Kosse]

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.

[Jeremy Braun]

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.

[Alexander Schuch]

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.