Opened 11 years ago

Closed 6 years ago

Last modified 16 months ago

#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 Changed 11 years ago by Tim Kosse

Most likely your server disobeys the MDTM specifications.

To further analyze the problem do the following:

  1. Enable "show raw directory listings" in the settings dialog
  2. Restart the client
  3. Connect to the server
  4. Attach contents of message log here

comment:2 Changed 8 years ago by paul

Operating system type: Windows
Operating system version: 7
Status: closedreopened

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 Changed 8 years ago by paul

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 Changed 8 years ago by Sean Devoy

Cc: sdevoy@… 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 Changed 6 years ago by Alexander Schuch

Resolution: duplicate
Status: reopenedclosed

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 Changed 16 months ago by ashrafel

Cc: ashrafel added
Note: See TracTickets for help on using tickets.