Change Directory (CD) on remote directory locks FileZilla.

[Sir Barrington]

Currently using a PC with Windows 10, up to date apart from KB503441 (FYI but not relevant).
Currently using the most up to date version of FileZilla 3.67.0.
Connection to the server is good and quick and changing directories is okay apart from when I CD to a directory that has a large number of files (over 6K).
I can download from the remote server from the other directories without a problem.
I have increased the timeout on FileZilla to several hours and after that time it is still locked up.
I had the impression that there were no limits on the number of files (6,852), or the size of those files (the largest is about 7MB).
Cannot someone help me to overcome this problem.
Thanks in advance.

[botg]

FileZilla can easily handle directories with over a million files.

What precisely do you mean by "lock up"?

[Sir Barrington]

Re "What do I mean by locks up".

The 'bad' directory is still highlighted, but the mouse can move but attempting to click on another directory does nothing except 'ding the bell'.
I have to close the window, else it's just going to sit there for ever (or at least 4 hours as tested).

[Sir Barrington]

This is the situation, and it will just stay like that and FileZilla is just not usable, all that can be done is close it.

Screenshot 2024-05-26 222550.png (18.47 KiB) Viewed 735 times

Hope that helps.

[botg]

Most peculiar. At this point I would need a dump file with a snapshot of the program state to further diagnose this issue.

Please follow these steps in order to create a minidump:

• Download and extract the Process Explorer tool from https://learn.microsoft.com/en-us/sysin ... s-explorer
• Start FileZilla and get it to lock up
• Start Process Explorer with admin rights
• Find filezilla.exe in the process list, right-click it and in the context menu, click Create Dump -> Create Minidump...
• Last but not least, please email the created file to tim.kosse@filezilla-project.org

Afterwards you can delete Process Explorer again.

[Sir Barrington]

I will do the dump when I get back to my PC, in the meantime can you clarify what you mean by the state of FileZilla at the time of the problem as I believe that is what I supplied in the snapshot above (without any personal info).

[botg]

The internal state of the program, I need to know where exactly it gets stuck. Essentially the stack traces of all running threads and the load addresses of all loaded modules.

[Sir Barrington]

Apologies, I misinterpreted your request as 2 different things - You’ll get the dump in about 5 - 6 hours.

[Sir Barrington]

Email sent about half an hour ago.
TIA

[botg]

Unfortunately nothing conclusive in the dump. All threads just sit there waiting for work, even the UI thread waits for input.

As for the loaded modules, I noticed that there are a couple of shell extensions and their depencencies coming from Microsoft Office and OneDrive:

c:\Program Files\Common Files\microsoft shared\OFFICE14\Cultures\OFFICE.ODF
c:\Program Files\Microsoft Office\Office14\1033\GrooveIntlResources.dll
c:\Program Files\Microsoft Office\Office14\GROOVEEX.DLL
C:\Users\<redacted>\AppData\Local\Microsoft\OneDrive\24.010.0114.0003\FileSyncShell64.dll
C:\Windows\WinSxS\amd64_microsoft.vc90.atl_1fc8b3b9a1e18e3b_9.0.30729.6161_none_0a1fd3a3a768b895\ATL90.dll

I suggest trying to uninstall these extensions and see if that makes any difference. Beyond that I'm clueless and out of ideas.

[Sir Barrington]

Before I attempt to uninstall bits of Office etc, I decided to try the same thing on my Win 11 PC.
So I have just finished downloading the latest FileZilla on my Win 11 PC (which is up to date) and ...

Drum roll .... Win 11 reacts in the same way, with all other folders on the server working correctly except for the images folder.
i.e. The problem is not restricted to Win 10 OS.

Now I know that the folder in question on the server has been built with images uploaded over many years, so it is possible that the client system used has changed (i.e. different PCs with different names etc).
It is thus possible that the permissions for the images MAY NOT be identical in that folder, and thus some images MIGHT be unreadable.
Obviously the old standard FTP didn't have a problem with it as I was happily uploading a week or so ago.

Thus my question here is, can an unreadable file cause FileZilla to lock up and behave as described?

[botg]

Obtaining directory listings doesn't open the remote files to begin with. Listings itself failing is also a common occurrence, it's over the network after all. If that would cause FileZilla to lock up, the forums would be full with complaints.

Could the same shell extensions be installed on both machines, tripping up on some type of file extension in the target directory?

Knowing that the server sends as listing might be useful. Please enable logging to file in the settings dialog of FileZilla and restart the client. Then on the debug page in the settings, set the debug log level to 5 and enable "Show raw directory listings". Now connect to the server and try to access the haunted directory. Last but not least, please send the log file to the same address as you did the minidump earlier.

[Sir Barrington]

I have followed the instructions exactly, except the highest debug level is 4 not 5. (there are 5 labelled 0 thru 4).
I have sent the log file by Email a few minutes ago .
This should help identify where the problem lies.

Last set of statements were:-

2024-05-30 17:28:45 61312 1 Trace: Remote working directory is /
2024-05-30 17:28:45 61312 1 Trace: CSftpConnectOpData::ParseResponse() in state 3
2024-05-30 17:28:45 61312 1 Trace: CControlSocket::ResetOperation(0)
2024-05-30 17:28:45 61312 1 Trace: CSftpConnectOpData::Reset(0) in state 3
2024-05-30 17:28:45 61312 1 Trace: CFileZillaEnginePrivate::ResetOperation(0)
2024-05-30 17:28:45 61312 1 Trace: CControlSocket::SendNextCommand()
2024-05-30 17:28:45 61312 1 Trace: CSftpListOpData::Send() in state 0
2024-05-30 17:28:45 61312 1 Status: Retrieving directory listing of "/htdocs/category_pics"...
2024-05-30 17:28:45 61312 1 Trace: CSftpChangeDirOpData::Send() in state 0
2024-05-30 17:28:45 61312 1 Trace: CSftpChangeDirOpData::Send() in state 2
2024-05-30 17:28:45 61312 1 Command: cd "/htdocs/category_pics"
2024-05-30 17:29:25 61312 1 Response: New directory is: "/htdocs/category_pics"
2024-05-30 17:29:25 61312 1 Trace: CSftpChangeDirOpData::ParseResponse() in state 2
2024-05-30 17:29:25 61312 1 Trace: CControlSocket::ResetOperation(0)
2024-05-30 17:29:25 61312 1 Trace: CSftpChangeDirOpData::Reset(0) in state 2
2024-05-30 17:29:25 61312 1 Trace: CSftpListOpData::SubcommandResult(0) in state 1
2024-05-30 17:29:25 61312 1 Trace: CControlSocket::SendNextCommand()
2024-05-30 17:29:25 61312 1 Trace: CSftpListOpData::Send() in state 2
2024-05-30 17:29:25 61312 1 Trace: CSftpListOpData::Send() in state 3
2024-05-30 17:29:25 61312 1 Command: ls
2024-05-30 17:29:25 61312 1 Status: Listing directory /htdocs/category_pics
2024-05-30 17:31:02 61312 1 Error: Connection timed out after 60 seconds of inactivity
2024-05-30 17:31:02 61312 1 Trace: CControlSocket::DoClose(2050)
2024-05-30 17:31:02 61312 1 Trace: CControlSocket::ResetOperation(2114)
2024-05-30 17:31:02 61312 1 Trace: CSftpListOpData::Reset(2114) in state 3
2024-05-30 17:31:02 61312 1 Error: Failed to retrieve directory listing
2024-05-30 17:31:02 61312 1 Trace: CFileZillaEnginePrivate::ResetOperation(2114)
2024-05-30 17:31:26 61312 1 Trace: CControlSocket::DoClose(66)
2024-05-30 17:31:26 61312 1 Trace: CControlSocket::ResetOperation(66)
2024-05-30 17:31:26 61312 1 Trace: CFileZillaEnginePrivate::ResetOperation(66)
2024-05-30 17:31:26 61312 1 Trace: CControlSocket::DoClose(66)
2024-05-30 17:31:26 61312 1 Trace: CControlSocket::ResetOperation(66)
2024-05-30 17:31:26 61312 1 Trace: CFileZillaEnginePrivate::ResetOperation(66)

[botg]

Nothing unusual in the log, it shows a listing attempt failing with a timeout, followed by an automatic retry, ending in another timeout. Nothing that would indicate a lock up of the client.

[Sir Barrington]

By lockup, I mean that the FileZilla Client is just stuck waiting for the server to respond, which it never does.
I can move the mouse pointer but nothing works, except minimize the window and close the window for the client.

As the client is waiting for a response from the server, the problem has to be on the server end.
But we know that other directories work fine but the particular one with a large number of files is a problem.
Surely the server should provide an error message after a certain amount of time - remember I let it 'run' (except it was not apparently doing anything) for 4 hours.
Is there any pertinent questions I can ask my host provider with regard to this problem?