Compatibility Issue? (Infinite Directory Recursion)

[rsmck]

Describe the bug

This may be thirdparty but as it is only experienced with Cyberduck, and not using the command line sftp client then I felt I should raise it, hopefully the attached log will help.

The SFTP server in this case is an Audiocodes server so, unfortunately, without access to one of their products it may be difficult to reproduce. I cannot reproduce this with an OpenSSH or Cerberus SFTP server.

To Reproduce
Steps to reproduce the behavior:

Connect to the AudioCodes SFTP server
Change directory to any directory
Attempt to download a file (this results in a 0 byte file)
Attempt to double click a file again
All files are now directories with infinite recursion

Expected behavior
I'd expect the file to be downloaded, and not turn into a directory.

Desktop (please complete the following information):

• OS: MacOS
• Version Version 9.0.2 (42108)

Log Files
Attached as requested

Additional context
I expect this may be a third party issue, but I've not managed to reproduce it with any client other than Cyberduck, so if there's an incompatibility here due to adherence to a specific standard, or lack thereof, apparent from the log file please let me know and I will refer it to the hardware vendor! I don't want to blame Cyberduck if it's not your fault :)
cyberduck.log

[dkocher]

The log shows changing the directory to debug-recording

2024-11-07 11:35:36,015 [main] DEBUG ch.cyberduck.ui.cocoa.controller.BrowserController - Set working directory to Path{path='/debug-recording', type=[directory]}

Transferring file DR_2024_11_07_10.05.50_252.pcap.gz

2024-11-07 11:35:39,211 [Thread-316] DEBUG ch.cyberduck.core.transfer.TransferQueue - Add transfer Transfer{transferred=null, size=null, roots=[TransferItem{remote=Path{path='/debug-recording/DR_2024_11_07_10.05.50_252.pcap.gz', type=[file]}, local=Local{path='/Users/ross/Downloads/DR_2024_11_07_10.05.50_252.pcap.gz'}}], state=running, host=Host{protocol=Profile{parent=sftp, vendor=iterate GmbH, description=null, image=null}, region='null', port=22, hostname='172.31.0.4', credentials=Credentials{user='cmsuser', password='', tokens='TemporaryAccessTokens{accessKeyId='', secretAccessKey='', sessionToken='', expiryInMilliseconds=9223372036854775807}', oauth='OAuthTokens{accessToken='', refreshToken='', idToken='', expiryInMilliseconds=9223372036854775807}', identity=null}, uuid='0bc000cc-946f-4b98-bfdb-7422e6f60939', nickname='AC-172.31.0.4', defaultpath='null', workdir=null, custom=null, labels=[]}} to queue

Attributes in file transfer status hows a file length of 0

2024-11-07 11:35:39,918 [O6qhQ5mz-transfer-1] INFO  ch.cyberduck.core.worker.AbstractTransferWorker - Determined transfer status TransferStatus{rename=Rename{local=null, remote=null}, exists=false, append=false, segment=false, offset=0, length=0, checksum=null, mime='null', permission=r--r--r-- (444), acl={}, encryption=none, storageClass='null', modified=-1, created=null, parameters={}, metadata={}, lockId=null, region=null, part=null, filekey=null} of Path{path='/debug-recording/DR_2024_11_07_10.05.50_252.pcap.gz', type=[file]} for transfer TransferCallable{file=Path{path='/debug-recording/DR_2024_11_07_10.05.50_252.pcap.gz', type=[file]}, local=Local{path='/Users/ross/Downloads/DR_2024_11_07_10.05.50_252.pcap.gz'}}

I suspect this to be an interoperability issue with the STAT response from the server for a file. Other client implementations may not query the file prior transfer but rely on the values obtained from READDIR instead.

[rsmck]

Ah, that makes sense, thank you.

Is there any way to have Cyberduck show the actual STAT request/response?

It wouldn't surprise me if their implementation is broken :D