Opened 2 months ago

Closed 2 months 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)

FileZilla.log (10.2 KB ) - added by Luke Foley 2 months ago.
FileZilla log file
EmptyDirectoryListing.png (89.7 KB ) - added by Luke Foley 2 months ago.

Download all attachments as: .zip

Change History (4)

by Luke Foley, 2 months ago

Attachment: FileZilla.log added

FileZilla log file

by Luke Foley, 2 months ago

Attachment: EmptyDirectoryListing.png added

comment:1 by Luke Foley, 2 months 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 Tim Kosse, 2 months ago

Resolution: rejected
Status: newclosed

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.

Note: See TracTickets for help on using tickets.