Opened 4 years ago
Closed 4 years ago
#12248 closed Bug report (rejected)
Empty directory listing when MLSD is used
Reported by: | Luke Foley | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | MLSD, Client, Empty Directory Listing | Cc: | |
Component version: | 3.49.1 | Operating system type: | Windows |
Operating system version: | 10 (Education Edition) |
Description
Good afternoon,
I've been developing a small FTP Server for use in an embedded project, and have been using the FileZilla Client as my go-to client for testing each part of the project.
I've come across an issue where FileZilla Client shows "Empty directory listing" when using the MLSD command, but works OK if I disable MLSD support and it reverts back to the LIST command.
This issue is only present in the FileZilla Client on Windows.
The same version of FileZilla on an Ubuntu machine works fine and directory listing works as expected for both LIST/NLST and MLSD.
Additionally, other FTP Clients for Windows work OK when using the MLSD command, so I'm hesitant to believe it's the server that's at fault.
I've attached a copy of the log (in Verbose mode) for your review, although I can't see any errors myself.
Please don't hesitate to let me know if you need further information.
Attachments (2)
Change History (4)
by , 4 years ago
Attachment: | FileZilla.log added |
---|
by , 4 years ago
Attachment: | EmptyDirectoryListing.png added |
---|
comment:1 by , 4 years ago
Although I was hesitant to believe it was the server at fault, I've just found the issue (and it was indeed the server)
The server was outputting the MLSD modify fact value in an incorrect format.
It seems that the Linux version of the FileZilla Client is able to "handle" this error, whereas the Windows Client fails the directory listing entirely.
Although the issue was with the server, not sure if there's anything to be done with the Filezilla Client to handle this on Windows? I assume not, but thought it's worth asking.
comment:2 by , 4 years ago
Resolution: | → rejected |
---|---|
Status: | new → closed |
Rejected as it's not a bug in FileZilla.
As for the different behaviour, it depends on the size of time_t, whether it's 32bit or 64bit, and also on the limits of the systems' various time conversion function. Based o n the log, the modification time of the files as sent by the server is in the year 1597, which computers struggle to represent in their native time format.
FileZilla log file