Files with modified date of 29th February cannot be transferred by read-only users via SFTP or FTP

[Graham Smith]

I am running a Sun Solaris UNIX system with a future date. When the system created files dated 29th February 2012 and I tried to transfer them back to a windows machine, FileZilla is incorrectly appending the date to the start of the file name, thus making it impossible to transfer the files. Its some sort of leap year bug in the software.

On Solaris box:

$ ls | grep Bulk
Bulk_STIP_PQ_jeconjrnl1.dat
$ pwd
/var/tmp

$ ls -ltr | grep Bulk
-rw-r--r-- 1 jrnlextr intrfcs 2130198528 Feb 29 13:27 Bulk_STIP_PQ_jeconjrnl1.dat

Filezilla attempted transfer:

Status: Starting download of /var/tmp/Feb 29 13:27 Bulk_STIP_PQ_jeconjrnl1.dat
Command: get "Feb 29 13:27 Bulk_STIP_PQ_jeconjrnl1.dat" "C:\FTL Retirement\Bulk STIP\Feb 29 13_27 Bulk_STIP_PQ_jeconjrnl1.dat"
Error: /var/tmp/Feb 29 13:27 Bulk_STIP_PQ_jeconjrnl1.dat: open for read: no such file or directory
Error: File transfer failed

[jylenhof]

Confirming this bug... with Linux

[Anon]

I have a number of files on my server dated Feb. 29, 2008, and I'm having the exact same issue. As my server is running on Windows 7, I'm pretty sure the issue isn't related to the server OS. (I've thus taken the liberty of removing "Solaris UNIX" from the ticket title.)

I've also confirmed that the bug does not occur when connecting to the server using FTPS (implicit), only SFTP, and it does not occur over SFTP when using an alternate client (I tested with WinSCP). Therefore, this bug seems to be unique to FileZilla Client's implementation of SFTP/SCP.

Summary:

Server OS: Windows 7
Server Software: Cerberus FTP Server
Client OS: Windows 7, Windows XP (confirmed on both)

Tested:

FileZilla 3.7.3 using SFTP -> leap year bug occurs for files dated Feb 29, 2008
FileZilla 3.7.3 using FTPS -> leap year bug does not occur
WinSCP using SFTP -> leap year bug does not occur

Example logs:

FileZilla Client listing a file over SFTP (bug occurs):
-rw-rw-rw- 1 0 0 36223 Feb 29 14:32 tsuki 3km.jpg

FileZilla Client listing a file over FTPS (bug does not occur):
size=36223;modify=20080229053232;create=20131027153737;perm=awrdf;type=file; tsuki 3km.jpg

[John]

This bug still exists, and affects files created Feb 29, 2016 (this leap year). The "Last Modified" shows up at the beginning of the filename (and thus it cannot be downloaded, since the filename now appears to have a colon in the middle of it). The "Last Modified" column is null (but only for files created on 2/29).

Interestingly, an administrator account that has read-write access can view and download these files normally - this problem only seems to affect end users who have read-only access to the files.

[John]

File with a "Date Modified" of Feb 29, from the point of view of a user with read-only access

[John]

File with a "Date Modified" of Feb 29, from the point of view of an admin with read+write access

[John]

This issue still exists in the latest version of Filezilla on Windows. I've attached screenshots, and am willing to provide more information if needed.

[Tim Kosse]

This bug has already been fixed a few years ago in FileZilla 3.20.0

[Tim Kosse]

Since 3.20.0 the server-provided "filename" field of the SSH_FXP_NAME packet takes precedence of the parsed filename from the "longname" field of said packet, which comes in an unspecified format.

If you still experience this in 3.20.0 or later it means that the server itself is sending a wrong "filename" field.