FileZilla client showing the wrong year

[xeon]

Hello,

I'm using vsftpd 3.0.2 as the server and the latest version of FileZilla Client. It seems on the last day of certain months (one of them being November), that any file modified or created on a server with a timezone that hits the 1st of the month (right at 00:00) before the client, will start showing an incorrect last modified year. It always seems to reduce the year by 1, for example 2013 to 2012.

So for example, right now it's 04:00 UTC on my test server, but my local client machine is 23:00, starting at 00:00 UTC on the server, any file modified or created is now showing the year 2012 instead of 2013. Once my local client timezone hits 00:00, it will then display 2013 in FileZilla Client upon refreshing the listing.

I've confirmed on the server-end that the year shows correctly on the filesystem, I've also tested with numerous other FTP clients and they all show the correct year.

Any ideas? Thanks.

[botg]

If you enable "show raw directory listings" in the settings dialog of FileZilla, what is being displayed there and what exactly is displayed in the file list instead?

[xeon]

If you enable "show raw directory listings" in the settings dialog of FileZilla, what is being displayed there and what exactly is displayed in the file list instead?

I set my local client date back to November 30th to reproduce this, since it already passed.

The raw listing shows the following:

15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Dec 02 18:48 test 9

The file listing shows 2012-12-02 13:48, all the other files listed here show 2013 correctly for the year.

Full log is below:

15:39:24 Status: Connecting to 84.29.1.8:21...
15:39:24 Status: Connection established, waiting for welcome message...
15:39:24 Response: 220 (vsFTPd 3.0.2)
15:39:24 Command: USER testing
15:39:24 Response: 331 Please specify the password.
15:39:24 Command: PASS ****************************
15:39:24 Response: 230 Login successful.
15:39:24 Command: SYST
15:39:24 Response: 215 UNIX Type: L8
15:39:24 Command: FEAT
15:39:24 Response: 211-Features:
15:39:24 Response: AUTH TLS
15:39:24 Response: EPRT
15:39:24 Response: EPSV
15:39:24 Response: MDTM
15:39:24 Response: PASV
15:39:24 Response: PBSZ
15:39:24 Response: PROT
15:39:24 Response: REST STREAM
15:39:24 Response: SIZE
15:39:24 Response: TVFS
15:39:24 Response: UTF8
15:39:24 Response: 211 End
15:39:24 Command: OPTS UTF8 ON
15:39:24 Response: 200 Always in UTF8 mode.
15:39:24 Status: Connected
15:39:24 Status: Retrieving directory listing...
15:39:24 Command: PWD
15:39:24 Response: 257 "/"
15:39:24 Command: TYPE I
15:39:24 Response: 200 Switching to Binary mode.
15:39:24 Command: PASV
15:39:24 Response: 227 Entering Passive Mode (84,29,1,8,52,63).
15:39:24 Command: LIST
15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Oct 10 03:47 test 1
15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Oct 20 20:44 test 2
15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Oct 23 01:13 test 3
15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Oct 30 01:15 test 4
15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Nov 05 15:01 test 5
15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Nov 13 11:54 test 6
15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Nov 19 17:45 test 7
15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Nov 27 16:44 test 8
15:39:24 Listing: -rw-r--r-- 1 0 0 900000000 Dec 02 18:48 test 9
15:39:24 Response: 150 Here comes the directory listing.
15:39:24 Response: 226 Directory send OK.
15:39:24 Status: Calculating timezone offset of server...
15:39:24 Command: MDTM test 1
15:39:24 Response: 213 20131010034722
15:39:24 Status: Timezone offsets: Server: 0 seconds. Local: -18000 seconds. Difference: -18000 seconds.
15:39:24 Status: Directory listing successful

[botg]

Difficult to fix. Wouldn't it be possible to instead upgrade to a server that supports the superior MLSD command?

[xeon]

Difficult to fix. Wouldn't it be possible to instead upgrade to a server that supports the superior MLSD command?

There aren't many good choices for a *nix environment, I'm afraid. vsftpd is, by far, the best I've come across, even though it does lack MLSD support.

Since it's difficult to fix, and no one else has complained about it (I think?), it's probably fine to disregard. It's a very rare occurrence anyway, and requires some pretty specific circumstances.

[track_this]

What about this is possibly difficult to fix? Seems like a pretty clear example of doing your own time/data calculations and getting it wrong, which is all too common. I can only guess that some bizarre attempt to fix a year boundary glitch ended up creating a glitch on the change of each month, but I haven't the slightest idea how you even arrive at the point of implementing such nonsense. Altering a timestamp by no more than 24 hours should not be that hard even if you insist on doing it yourself rather than using one of the proven date manipulation functions.

[botg]

It's impossible to get the date boundary correct with LIST. Regardless how you do it, there's always some server where the time will be wrong. This can only be fixed using MLSD.

[track_this]

LIST will give the year if it differs from current year. Thus, if the year is not present it's the current year except for the one case at dec31/jan1 with sufficient timezone difference. I suppose that is the case you were trying to correct by subtracting a year, but you do it on all month boundaries instead of only the year boundary. Sloppy hack gone awry, you need to inspect the month numbers as well, not just the day numbers, for this workaround to solve a problem rather than creating problems.

But really, why would you be using the data from LIST when there is clearly an MDTM issued and the full timestamp without any ambiguity comes back? The OP was talking about test9 but the MDTM was issued on test1 and then a calculated timezone offset is shown. I can only guess you are using the first file from the LISTing to calculate the timezone offset and then apply a correction to all the other results of LIST. That might seem like a decent optimization compared to issuing a MDTM on every file when you are connected to a server that lacks MLSD support. However, there is a shortcoming in that approach that you've identified so you know it has a caveat. Rather than doing some hacky date math, whenever you hit a date that isn't easily handled without ambiguity, you should just use MDTM instead of attempting (and failing) to work from the LIST data alone.

[ItsBrent]

I just wanted to let you know I saw the problem. I am pleased to know I am not going crazy. I am surprised such a wonderfull program has this glich. But I am sure there are more important problems to deal with. Thanks for all your hard work creating this free program.

[botg]

Just switch to a server supporting MLSD and all problems go away.