Incorrect timestamp YEAR applied by client 3.9.0.3

[Donna Courtney]

I use the FileZilla client to both place and retrieve files on a secure server.

The client is changing the YEAR portion of the timestamp on files from 2014 to 2013.

I have my settings to "preserve timestamp" and the month, day and time remain correct, but the YEAR is changed from 2014 to 2013.

When I transfer a file from my network location to the server, the YEAR changes to 2013.

When I transfer a file from the server to my network, the same thing happens.

DISPLAY observations:

When I simply VIEW files newly placed on the server by a sender other than myself, in FileZilla the YEAR appears changed to 2013.

However, when I VIEW that same file on the server with a different FTP tool (such as WinSCP) the YEAR on the file correctly appears as 2014.

Files on my own network that I simply VIEW in FileZilla remain unchanged with the correct 2014 YEAR. The YEAR on my files changes from 2014 to 2013 when I transfer to the server side using FileZilla.

This is NOT solely a display issue, because on files I transfer off the server to my network, the YEAR is actually changed on the file timestamp.

FileZilla Client Version Information:

---

Version: 3.9.0.3

Build information:

Compiled for: i686-w64-mingw32
Compiled on: x86_64-unknown-linux-gnu
Build date: 2014-08-13
Compiled with: i686-w64-mingw32-gcc (GCC) 4.9.1
Compiler flags: -g -O2 -Wall -g -fexceptions -std=gnu++11

Linked against:

wxWidgets: 3.0.2
GnuTLS: 3.2.16
SQLite: 3.8.4.3

Operating system:

Name: Windows 7 (build 7601, Service Pack 1)
Version: 6.1
Platform: 32 bit system

[Tim Kosse]

Please verify that both the client and server machines have the correct time and that their timezone is properly set.

To synchronize times, you can use any decent NTP client and direct it at pool.ntp.org

Does this error still persist after synchronizing times and checking for correct timezone configuration?

[Donna Courtney]

I have worked with my IT support and have verified that both client and server machines have correct time and timezones.

This did not resolve the issue.

One of my IT colleagues also uses FileZilla. He had 3.9.0.2 installed, and was not having this issue. As a test, he upgraded to 3.9.0.3 and is now having the same problem that I am.

[Tim Kosse]

Please enable "Show raw directory listings" in the settings dialog of FileZilla and post a complete and unmodified log from obtaining a directory listing, as well as a corresponding screenshot of FileZilla showing the files with the wrong timestamp.

[Donna Courtney]

screenshot of files with YEAR altered by FileZilla

[Donna Courtney]

screenshot of changed file properties

[Donna Courtney]

Status: Connecting to 159.36.2.9...
Response: fzSftp started
Command: open "courtnd@159.36.2.9" 22
Command: Pass:
Status: Connected to 159.36.2.9
Status: Retrieving directory listing...
Command: pwd
Response: Current directory is: "/"
Command: ls
Status: Listing directory /
Listing: drwxr-xr-x 7 0 223 8 Jul 17 15:45 ./
Listing: drwxr-xr-x 7 0 223 8 Jul 17 15:45 ../
Listing: drwxrwx--x 22 0 220 23 Jun 6 18:12 trauma/
Listing: drwxrwsr-x 78 0 217 79 Jul 31 18:50 hdd/
Listing: -rw-r--r-- 1 0 0 0 Feb 9 16:20 You_Are_in_the_BPHS_Directory
Listing: drwxrwsr-x 11 0 219 12 Mar 31 22:58 bdr/
Listing: drwxrwx--x 6 0 298 6 Sep 13 22:09 ss/
Listing: drwxrwsr-x 93 0 218 94 May 12 19:15 acr/
Status: Calculating timezone offset of server...
Command: mtime "trauma"
Response: 1370542337
Status: Timezone offsets: Server: 31536000 seconds. Local: -25200 seconds. Difference: -31561200 seconds.
Status: Directory listing successful
Status: Retrieving directory listing...
Command: cd "hdd"
Response: New directory is: "/hdd"
Command: ls
Status: Listing directory /hdd
Listing: drwxrwsr-x 78 0 217 79 Jul 31 18:50 ./
Listing: drwxr-xr-x 7 0 223 8 Jul 17 15:45 ../
Listing: drwxrws--x 2 0 217 3 Aug 28 22:21 N_Cochise/
Listing: drwxrws--x 2 0 217 2 Sep 3 20:29 HS_Scotts/
Listing: drwxrws--x 2 0 217 7 Aug 18 16:16 Aurora_Tempe/
Listing: drwxrws--x 2 0 217 3 Sep 3 15:21 Promise/
Listing: drwxrws--x 2 0 217 3 Jul 23 17:48 Auditor/
Listing: drwxrws--x 4 0 217 5 Feb 3 16:42 JCL/
Listing: drwxrws--x 5 0 217 6 Oct 23 22:28 Kindred/
Listing: drwxrws--x 2 0 217 8 Aug 27 19:54 MMC/
Listing: drwxrws--x 2 0 217 10 Jul 28 18:54 Florence_Anthem/
Listing: drwxrws--x 2 0 217 7 Jul 22 18:12 Guidance/
Listing: drwxrws--x 2 0 217 6 Aug 13 22:38 Valley/
Listing: drwxrws--x 2 0 217 3 Jan 14 19:39 ASU/
Listing: drwxrws--x 2 0 217 8 Aug 19 18:09 Payson/
Listing: drwxrws--x 2 0 217 3 Aug 14 13:29 HS_East_Valley/
Listing: drwxrws--x 2 0 217 7 Aug 12 1:24 Surg_Spec_AZ/
Listing: drwxrws--x 2 0 217 3 Aug 28 13:49 La_Paz/
Listing: drwxrws--x 2 0 217 10 Aug 12 18:55 Mt_Graham/
Listing: drwxrws--x 2 0 217 7 Aug 20 16:31 Mtn_Vista/
Listing: drwxrws--x 2 0 217 7 Aug 26 23:32 Benson/
Listing: drwxrws--x 2 0 217 7 Aug 20 21:42 Sage/
Listing: drwxrws--x 2 0 217 13 Aug 19 22:17 KRMC/
Listing: -rw-rw---- 1 0 217 61 Dec 19 17:21 You_Are_in_the_HDD_Directory
Listing: drwxrws--x 2 0 217 2 Aug 27 21:29 HS_S_AZ/
Listing: drwxrws--x 2 0 217 10 Aug 27 1:49 Phx_Child/
Listing: drwxrws--x 2 0 217 14 Aug 18 20:44 CRH/
Listing: drwxrws--x 2 0 217 6 Aug 27 20:37 AZ_Ortho/
Listing: drwxrws--x 2 0 217 9 Aug 25 22:12 Wickenburg/
Listing: drwxrws--x 2 0 217 10 Aug 26 18:56 Wht_Mtn/
Listing: drwxrws--x 4 0 217 5 Sep 12 15:51 CHW/
Listing: drwxrws--x 2 0 217 3 Dec 23 19:14 Adamsville/
Listing: drwxrws--x 2 0 217 7 Aug 6 18:06 Cornerstone/
Listing: drwxrws--x 3 0 217 11 Aug 13 1:01 Havasu/
Listing: drwxrws--x 2 0 217 7 Aug 26 17:52 CCC/
Listing: drwxrws--x 2 0 217 2 Aug 20 16:29 HS_VOS/
Listing: drwxrws--x 2 0 217 9 Aug 27 1:02 SVRHC/
Listing: drwxrws--x 2 0 217 7 Aug 19 23:19 Remuda/
Listing: drwxrws--x 2 0 217 3 Aug 29 20:56 Valley_View/
Listing: drwxrws--x 2 0 217 8 Aug 12 19:38 Mtn_Valley_Rehab/
Listing: drwxrws--x 15 0 217 16 Oct 30 20:07 Banner/
Listing: drwxrws--x 2 0 217 10 Aug 27 16:50 TMC/
Listing: drwxrws--x 2 0 217 7 Aug 19 23:11 Oasis/
Listing: drwxrws--x 8 0 217 9 Aug 15 23:24 Abrazo/
Listing: drwxrws--x 2 0 217 2 Aug 6 16:29 Yuma_Rehab/
Listing: drwxrws--x 2 0 217 7 Aug 27 0:41 UMC/
Listing: drwxrws--x 2 0 217 3 Aug 26 22:35 Cobre_Valley/
Listing: drwxrws--x 5 0 217 6 Apr 16 21:26 Carondelet/
Listing: drwxrws--x 2 0 217 3 Aug 25 19:10 Sonora/
Listing: drwxrws--x 6 0 217 7 Jul 17 16:44 Select/
Listing: drwxrws--x 6 0 217 7 Dec 5 17:26 SHC/
Listing: drwxrws--x 2 0 217 3 Jan 23 21:33 Source_Medical/
Listing: drwxrws--x 2 0 217 7 Sep 2 20:47 Windhaven/
Listing: drwxrws--x 2 0 217 9 Aug 27 2:20 Little_Colorado/
Listing: drwxrws--x 2 0 217 3 Aug 27 15:46 Restora/
Listing: drwxrws--x 2 0 217 7 Aug 27 21:06 Sierra_Tucson/
Listing: drwxrws--x 2 0 217 7 Aug 27 0:09 UMC_South/
Listing: drwxrws--x 2 0 217 3 Jul 14 17:44 AZMD/
Listing: drwxrws--x 5 0 217 6 Mar 1 17:15 Iasis/
Listing: drwxrws--x 2 0 217 3 Aug 26 14:32 Haven/
Listing: drwxrws--- 2 0 217 7 Aug 26 23:49 Oasis_Behavioral/
Listing: drwxrws--x 4 0 217 5 Aug 15 18:47 N_AZ_Healthcare/
Listing: drwxrws--x 2 0 217 3 Sep 3 16:17 Oro_Valley/
Listing: drwxrws--x 2 0 217 3 Sep 2 14:36 Summit/
Listing: drwxrws--x 2 0 217 3 Sep 3 16:15 Northwest/
Listing: drwxrws--x 2 0 217 10 Aug 26 17:25 Yuma_Reg/
Listing: drwxrws--x 2 0 217 7 Sep 3 14:04 AZSJ/
Listing: drwxrws--x 2 0 217 3 Aug 25 17:30 St_Joe/
Listing: drwxrws--x 2 0 217 9 Aug 27 20:24 WARMC/
Listing: drwxrws--x 2 0 217 7 Aug 13 1:31 Aurora_Glendale/
Listing: drwxrws--x 2 0 217 7 Aug 20 17:18 WRMC_CTCA/
Listing: drwxrws--x 2 0 217 6 Aug 20 19:32 Los_Ninos/
Listing: drwxrws--x 2 0 217 10 Aug 12 1:59 Casa_Grande/
Listing: drwxrws--x 2 0 217 6 Aug 5 23:11 Freedom/
Listing: drwxrws--x 2 0 217 2 Aug 20 13:29 HS_Tucson/
Listing: drwxrws--x 2 0 217 10 Aug 26 22:59 Gilbert/
Listing: drwxrws--x 2 0 217 3 Aug 28 22:19 Copper_Queen/
Listing: drwxrws--x 2 0 217 10 Aug 25 20:19 Mayo/
Listing: drwxrws--x 4 0 217 5 Feb 15 20:12 Yavapai/
Status: Directory listing successful
Status: Retrieving directory listing...
Command: cd "AZ_Ortho"
Response: New directory is: "/hdd/AZ_Ortho"
Command: ls
Status: Listing directory /hdd/AZ_Ortho
Listing: drwxrws--x 2 0 217 6 Aug 27 20:37 ./
Listing: drwxrwsr-x 78 0 217 79 Jul 31 18:50 ../
Listing: -rw-rw---- 1 0 121 84 Jan 24 18:04 You_are_in_the_AZ_Ortho_directory
Listing: -rw-r--r-- 1 1054 217 47616 Aug 27 20:36 az_ortho_201401_feedback_a.doc
Listing: -rw-r--r-- 1 1054 217 1363456 Aug 27 20:33 az_ortho_201401_ip_081814_errors_1.xls
Listing: -rw-r--r-- 1 1054 217 39936 Aug 27 20:35 az_ortho_201401_feedback_a_details.doc
Status: Directory listing successful

[Tim Kosse]

This is a server issue.

Command: mtime "trauma"
Response: 1370542337

mtime retrieves timestamps via SSH_FXP_STAT which is required by the SFTP specifications to return the number of seconds since 1970-01-01 00:00:00 UTC (epoch)

The server says that the modification time of the directory trauma is 1370542337 seconds into the epoch.
Converted into human readable time, 1370542337 is 2013-06-06 18:12:17 UTC

drwxrwx--x 22 0 220 23 Jun 6 18:12 trauma/

In the human-readable directory listing, the timezone isn't standardized. To detect it, it needs to be calculated by comparing against the result from mtime.

It is common for Unix-style directories, for files younger than at most a year, a time is shown, for older files a year (and no time information).

So the directory trauma has a timestamp of 2014-06-06 18:12 in an unspecified timezone.

Comparing with the result of mtime, this means the server's timezone is UTC+8760. To normalize all timestamps to your own timezone (UTC-7) around a year worth of time needs to be subtracted from the times listed in the directory listing.

In conclusion, either the server returns the wrong timestamp in reply to SSH_FXP_STATUS or it returns the wrong timestamp in the directory listings.