STAT for listings works poorly or not at all #2445
Comments
Refer to https://trac.cyberduck.io/wiki/help/en/problems#ListingdirectoriesfailsorshowsnocontentFTP for how to disable the use of |
Unacceptable. STAT works reliably on NONE of the Solaris or Linux systems I access on a regular basis. That includes systems in many data centers spread world-wide. STAT may work in various places, but given the ubiquity of its not working right, it should be the last resort, not the first, and users should not need to resort to rather arcane, kludgey workarounds to make the product work on a reliable basis. LIST worked. STAT doesn't. Does "If it ain't broke, don't fix it" ring a bell? |
Replying to [comment:2 jeff.markel@gmail.com]:
{{STAT}}} was introduced because it does not need a second connection to be opened to the server and is much faster therefore. The fallback mechanism not working properly must be fixed, I agree. |
Can you please post some transcripts from View → Log Drawer for servers the file listing fails. |
Replying to [comment:9 dkocher]:
Attached some logs for you. I know that some of the clients I send files to use Cyberduck and I really cannot ask them to start farting around with the terminal so that I can implement the use of this server. |
Thanks for the transcript. The server response does not list any files in that folder. Does the server give a different listing when Replying to [comment:10 anonymous]:
|
Replying to [comment:12 dkocher]:
Yes this is a similar report however the solution in #2530 (disable STAT)did not work for me. I am having no problems accessing the site and directories via Transmit and CuteFTP. Attached are the 3 logs, before and from after each terminal command (with restarting Cyberduck after each process) The LIST command does not even seem to show the directories that STAT did (all be it empty) I have also attached a transcript log from CuteFTP where the LIST command seems to work properly |
That didn't work, tested 96490a9 with the configuration you suggested above. Cyberduck lists the top (two) folders and then nothing in those folders. Testing alongside transmit which is working properly. |
The folders I am trying to access contain invisible mac files such as :2eDS_Store. Since . and .. files caused a problem is it possible that these are also causing the same problem? |
Replying to [comment:15 anonymous]:
Again, please post the transcript from View → Log Drawer. |
Cyberduck 3 is unable to list files in some directories, on most FTP servers I've tried recently. Cyberduck 2.8.5 has no such problem. After some trial-and-error testing, I see that the STAT command works fine IF the directory is short, otherwise a LIST command is required. Using Cyberduck 3.0.3 (4180), here are two examples using Verizon's FTP server (215 UNIX Type: L8):
Cyberduck shows this: then it sits there forever making no further progress. Quit Cyberduck then
Cyberduck shows this: the above continues for a long long time then Cyberduck's list window is properly and fully populated. IMO this bug is a critical/blocker... It pretty much makes Cyberduck totally useless for many people. |
Two part fix suggestion:
Performance concern: If detecting the failure, aborting, and switching to the other command, takes too long, then the end user will perceive Cyberduck as being annoyingly slow. Might be a good idea to hit 'em with some status type dialog so they know what's happening. HTH,
|
Another example of a |
Replying to [comment:21 dkocher]:
Fixed in 5e2fefc. |
I consider this fixed with the latest commits. Please test the nightly build. |
Using Cyberduck 3.0.3 (4202), OS X 10.4.11, Java 1.5.0_16 with 'defaults write ch.sudo.cyberduck ftp.sendStatListCommand true'... Cyberduck still gets stuck in Verizon's ftp, just like reported (above). Instead of sitting forever tho, it now sits for half a minute or so then provides a window with no files listed. No error messages are thrown to system or console log. The log window shows the same as before: with 'defaults write ch.sudo.cyberduck ftp.sendStatListCommand false', Cyberduck works perfectly. |
We delay the resolution of the Verizon Compatibility issue. This is clearly a server bug as the response is never terminated. |
Milestone 3.2 deleted |
After installing 3.0.2 I found that directory listings from nearly all the servers I accessed (primarily Solaris and Linux) either returned nothing or timed out - and when retried, again returned nothing or timed out.
The change to use STAT instead of LIST seems to have broken Cyberduck, at least for me, to the point where it is absolutely unusable. I have backed off to 3.0.1 which (judging from the logs, uses LIST rather than STAT) works fine.
The text was updated successfully, but these errors were encountered: