Opened 17 years ago
Last modified 9 years ago
#2545 closed Feature request
always send Y-m-d hh:mm:ss for date/time in listing
|Reported by:||kjisi||Owned by:||Alexander Schuch|
|Keywords:||Cc:||kjisi, Alexander Schuch, koick|
|Component version:||Operating system type:|
|Operating system version:|
FileZilla Server seems to not correctly transfer the
remote file timestamp (modification time) correctly to
==> 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
Change History (11)
by , 17 years ago
comment:1 by , 17 years ago
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
Please let me know if you need anything more to get this
fixed soon. THANKS!!!
comment:2 by , 16 years ago
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.
by , 16 years ago
|Attachment:||FileZillaServer TimestampIssue.rar added|
Example files which work/don't work
comment:3 by , 16 years ago
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:
These files still have as timestamp[hour:min]=00:00 :
Thank you for your help!
File Added: FileZillaServer TimestampIssue.rar
comment:4 by , 16 years ago
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.
comment:5 by , 16 years ago
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.
comment:6 by , 16 years ago
To be clear, this is an issue with Filezilla server and not the client.
comment:7 by , 16 years ago
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.
comment:8 by , 16 years ago
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.
comment:9 by , 16 years ago
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.
FileZilla Client and Server logfile