always send Y-m-d hh:mm:ss for date/time in listing

[kjisi]

FileZilla Server seems to not correctly transfer the
remote file timestamp (modification time) correctly to
a client.

Example:
==> real time stamp: 2006-05-12 16:34:08

==> time stamp displayed by client

• FileZilla: 2006-05-12 (time field is empty!)
• magellan explorer: 2006-05-12 02:00:00
• windows explorer: 2006-05-12 00:00:00

==> time stamp used as modification time by
FileZillaClient, if downloaded with option "keep
remote file timestamp" set: 2006-05-12 00:00:00

[kjisi]

FileZilla Client and Server logfile

[koick]

I would argue that this is a duplicate of bug # 1499881.
(server v0.9.18 time zone issues). The filezilla server
version 0.9.17 worked fine, but with versions 0.9.18 and
0.9.19, most (but not all?) of the file times report as 00Z.
This is a show-stopper for me since I need to synchronize
files and the date/time needs to be reported correctly. So,
I have reverted to 0.9.17, but I'm missing the security
updates associated with 0.9.19.

You should be able to see this problem for yourself.
Install Firefox server, then use Firefox client (or any
other ftp client) to connect and you should see that the
filetimes show as 00Z.

Also, according to the changelog, this seems to be the
appropriate change:
​http://filezilla.cvs.sourceforge.net/filezilla/FileZilla%20Server/source/ControlSocket.cpp?r1=1.127&r2=1.126

Please let me know if you need anything more to get this
fixed soon. THANKS!!!

[Alexander Schuch]

The current version of FileZilla Server is 0.9.23. Can you please test that version and check if the problem still persists? According to the changelog timezone issues have been fixed.

[kjisi]

Example files which work/don't work

[kjisi]

I have just downloaded and checked the latest version of both the server 0.9.23 and client 2.2.29.

Now the timestamp works FOR SOME FILES, BUT NOT FOR OTHERS.

I am a little bit confused why it works for some files and not for others.
All are small text files, and some have the same filename extension, but are still treated differently by the server.

FileZilla Client displays no file time for the files in question in the remote window, and if downloaded, the time stamp is 00:00.
For files which work, FileZilla Client displays the time correctly and also the downloaded files have the correct time stamp.

I have attached the files I have used for testing, may be this helps in pinpointing the problem.

These files (in the attachment) work:

• custom.ctl
• test.txt

These files still have as timestamp[hour:min]=00:00 :

• Readme_reg_key.001.txt
• reg_key.009

Thank you for your help!

File Added: FileZillaServer TimestampIssue.rar

[Alexander Schuch]

The latest version of FileZilla 2 is 2.2.32. But can you please test with FileZilla 3.0.1, as FileZilla 2 is not developed anymore.

In the settings dialogue of FileZilla 3 in "debug" category, enable raw directory listings and then please attach the raw directory listing of the directory in question to this tracker. Thanks.

[koick]

Ah!, I think I understand. Now that you've asked to turn on the "raw directory listing" in the debug menu of the ftp client (v. 3.0.1). I can see that the returned date/times from FileZilla server (v.0.9.23) are in the default unix format. That is, that if the timestamp of a file/folder is within something like 6 months old, it will show the time of the file, otherwise instead it will only output the year (e.g. "Apr 17 2007" versus "Sep 05 12:34" [this year is implied]). Thus, if a folder/file is older than half a year, the time will not be returned and thus be represented by the clients as "00". You can play around with the 'touch' command on a file (to change its timestamp) and then 'ls -l' to see what I mean. (I am using the cygwin tools to run these commands in Windows)

I'd say what needs to happen is the server needs to ALWAYS return the times of files/folders with something akin to one of these three formats:

'ls --full-time' [which is equivalent to 'ls -l --time-style=full-iso'] (which always outputs date and time with decimal seconds)

'ls -l --time-style=long-iso' (which isn't desirable as it leaves off seconds)

'ls -l --time-style=+"%Y-%m-%d %H:%M:%S" (which outputs as: YYYY-MM-DD HH:MM:SS)

I assume there's got to be some standard output format for ftp servers which will be parsed correctly by clients, in which case you can use the latter one above to get it in the format it needs to be in.

Hope this helps.

[koick]

To be clear, this is an issue with Filezilla server and not the client.

[kjisi]

Yes, at least I think so.
I have not looked into the network traffic (because I don't know how to do this).

But I have tried these FTP CLIENTS: FileZilla, Magellan Explorer, TotalCommander, TJFTP, FTPWanderer

Also, I have another FTP server (RaidenFTPD) which transmits the files I sent with correct hour:min to these clients.

[Alexander Schuch]

@koick:
There is NO standard on how an FTP server is supposed to return the file list. Basically, it can use whatever format it likes. And this exactly is the problem for any FTP client trying to parse the directory listing of an FTP server.

So to me it looks as if this is not a bug, but a feature request for FileZilla Server. There should be a way to configure how date/time of items should be formatted in the output.

[Alexander Schuch]

As already mentioned, the output used by LIST is not defined, so whatever FileZilla Server uses is fine. And with compatibility in mind, the date/time formatting won't be changed anymore.

However, FileZilla Server supported the MLST command, which returns the directory listing in a more standardised format. So all that needs to be done is to instruct the FTP client to use MLST instead of LIST for fetching the directory listing.

FileZilla 3 doesn't yet use MLST - that's why the "issue" is visible with it as well.

Closing this item.