Opened 11 years ago
Closed 3 years ago
Last modified 3 years ago
#7885 closed Bug report (fixed)
Files with modified date of 29th February cannot be transferred by read-only users via SFTP or FTP
|Reported by:||Graham Smith||Owned by:|
|Keywords:||Leap Year February||Cc:|
|Component version:||Operating system type:||Windows|
|Operating system version:||Windows 10|
Description (last modified by )
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
$ 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
Change History (9)
comment:1 by , 11 years ago
|Priority:||normal → high|
comment:2 by , 9 years ago
|Summary:||Files with create date of 29th February 2012 cannot be transferred from Solaris UNIX → Files with create date of 29th February 2012 cannot be transferred using SFTP|
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.
Server OS: Windows 7
Server Software: Cerberus FTP Server
Client OS: Windows 7, Windows XP (confirmed on both)
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
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
comment:3 by , 7 years ago
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.
by , 3 years ago
|Attachment:||Filezilla Leap Year - User.png added|
File with a "Date Modified" of Feb 29, from the point of view of a user with read-only access
by , 3 years ago
|Attachment:||Filezilla Leap Year - Admin.png added|
File with a "Date Modified" of Feb 29, from the point of view of an admin with read+write access
comment:4 by , 3 years ago
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.
comment:5 by , 3 years ago
|Operating system version:||Windows XP → Windows 10|
|Priority:||high → blocker|
|Summary:||Files with create date of 29th February 2012 cannot be transferred using SFTP → Files with modified date of 29th February cannot be transferred by read-only users via SFTP or FTP|
comment:6 by , 3 years ago
|Status:||new → closed|
This bug has already been fixed a few years ago in FileZilla 3.20.0
comment:7 by , 3 years ago
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.
Confirming this bug... with Linux