#3698 closed Bug report (duplicate)
Dates on files
Reported by: | chadking | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | Cc: | chadking, Tim Kosse, sdevoy@…, ashrafel | |
Component version: | Operating system type: | Windows | |
Operating system version: | 7 |
Description
i am using FileZilla 3.1.1.1 with FreeFTPD server. When looking at the "last modified" date code on the files in Filezilla they are all wrong. most of them have dates of January 1969 or 1970. Has onyone else seen this issue? The dates on the files within windows are correct.
Change History (6)
comment:1 by , 16 years ago
comment:2 by , 13 years ago
Operating system type: | → Windows |
---|---|
Operating system version: | → 7 |
Status: | closed → reopened |
Timezone offsets: Server: 1324973220 seconds. Local: -18000 seconds. Difference: -1324991220 seconds.
I am having the same issue. Enabling "show raw directory listings" and navigating to the server shows the above line in the message log.
comment:3 by , 13 years ago
Listing directory /in/test/
Listing: drw-rw-rw 1 root root 0 Jan 19 09:01 .
Listing: drw-rw-rw 1 root root 0 Jan 19 09:01 ..
Listing: -rw-rw-rw 1 root root 3 Jan 19 09:01 hello.txt
Status: Directory listing successful
After navigating to a directory, the above shows in the log. Jan 19 is accurate, but in the file browsing area, it shows 1/23/1970 for the "last modified"
comment:4 by , 13 years ago
Cc: | added |
---|
I have additional information that explains WHEN and WHY this happens:
My Server is running FreeFTPd and I use it in sftp mode on Windows 2008 R2.
when connecting with FileZilla from my Windows 7 client, sometimes the dates are fine, others they are screwey. I have found that if the FIRST file or directory (alphabetically) is a Directory the mtime function fails when getting the timezone offset. If the first object of a FILE the mtime function succeeds and calculates the correct timezone offset.
Now, having observed that, I do not know if the "error/bug" is in FileZilla client or FreeFTPd server. Here is some sample output:
Status: Calculating timezone offset of server...
Command: mtime "Admin"
Response: 4294967295
Status: Timezone offsets: Server: 1312383480 seconds. Local: -18000 seconds. Difference: -1312401480 seconds.
Status: Calculating timezone offset of server...
Command: mtime "AboutUs.html"
Response: 1309747324
Status: Timezone offsets: Server: -18000 seconds. Local: -18000 seconds. Difference: 0 seconds.
I suppose creating an aaaa.txt file in the login folder would be a workaround.
Hope that helps.
Sean
comment:5 by , 11 years ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
As per specification (http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02), "mtime" is supposed to return the modification time of the given file system object. The server you are referring to returns "4294967295", which simply is wrong. So to properly fix the problem is to fix the server.
However, I created a feature request #8860 which is about disabling the timezone detection completely.
comment:6 by , 6 years ago
Cc: | added |
---|
Most likely your server disobeys the MDTM specifications.
To further analyze the problem do the following: