Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read timed out failure for large file upload #10834

Closed
cyberduck opened this issue Oct 7, 2019 · 8 comments
Closed

Read timed out failure for large file upload #10834

cyberduck opened this issue Oct 7, 2019 · 8 comments
Labels
bug ftp FTP Protocol Implementation thirdparty Issue caused by third party

Comments

@cyberduck
Copy link
Collaborator

798541c created the issue

This one has me astonished... Steps to reproduce:

  1. Upload a large file.
  2. Upload reaches 100.0%.
  3. Cyberduck deletes the remote file it just uploaded, and restarts the upload (this time at a speed that is several times slower than the available bandwidth and original speed, for some reason).

My guess is that the threshold is 2GB: I uploaded a 1.1GB file that did not exhibit that behavior, followed by a 3.2GB file that did.

I have experienced this behavior in two different systems working with different files and different FTP servers.

  • Cyberduck 6.9.4 on OS X 10.10.5, via FTP.
  • Cyberduck 7.1.0 on OS X 10.13.6, via FTPS.
    Same behavior.

This has been reproducible, happens every time to me.

Tried with "upload with temporary filename" both enabled and disabled - same behavior.
"Always overwrite when reloading" has always been disabled, and "Existing files" is set to "Prompt".

Only workaround I found is... to use FileZilla. It doesn't exhibit this problem at all, with the same files and FTP server.
Needless to say, this is pretty insane/maddening. But I've been loyal to Cyberduck for years and am willing to help troubleshooting this.

Log attached as file.


Attachments

@cyberduck
Copy link
Collaborator Author

@dkocher commented

DELE /public_html/clients/nevenka/Complete performance.mp4-nC9toDgL
250 Deleted /public_html/clients/nevenka/Complete performance.mp4-nC9toDgL

@cyberduck
Copy link
Collaborator Author

@dkocher commented

The log indicates that Upload with temporary filename is enabled.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

I cannot seem to reproduce the issue

STOR /sandbox/TRAC-10834/10-3.png-OCrI0FZC
150 Ok to send data.
226 Transfer complete.
RNFR /sandbox/TRAC-10834/10-3.png-OCrI0FZC
350 Ready for RNTO.
RNTO /sandbox/TRAC-10834/10-3.png
250 Rename successful.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please post the transcript from the log drawer of the Transfers window. Choose ⌘-L on Mac or right-click the toolbar from the Transfers window and choose Log on Windows.

@cyberduck
Copy link
Collaborator Author

798541c commented

Updated to latest 7.1.2, still happens.
Here is the transfer log:

CWD /public_html/clients/nevenka
250 OK. Current directory is /public_html/clients/nevenka
TYPE A
200 TYPE is now ASCII
PASV
227 Entering Passive Mode (198,252,102,197,124,106)
MLSD
150 Accepted data connection
type=cdir;sizd=4096;modify=20191026195506;UNIX.mode=0755;UNIX.uid=1121;UNIX.gid=1126;unique=821g6724c1c; .
type=pdir;sizd=4096;modify=20191006061520;UNIX.mode=0750;UNIX.uid=1121;UNIX.gid=99;unique=821g6722e9e; ..
type=file;size=129;modify=20191005182755;UNIX.mode=0644;UNIX.uid=1121;UNIX.gid=1126;unique=821g6724c1f; .htaccess
type=file;size=337;modify=20190202202357;UNIX.mode=0644;UNIX.uid=1121;UNIX.gid=1126;unique=821g6724c1d; index.php
226-Options: -a -l 
226 4 matches total
TYPE I
200 TYPE is now 8-bit binary
PASV
227 Entering Passive Mode (198,252,102,197,127,233)
STOR /public_html/(.....).mp4
150 Accepted data connection
TYPE I
200 TYPE is now 8-bit binary
PASV
227 Entering Passive Mode (198,252,102,197,122,225)
STOR /public_html/(.....).mp4
150 Accepted data connection

@cyberduck
Copy link
Collaborator Author

798541c commented

Replying to [comment:4 dkocher]:

I cannot seem to reproduce the issue
.

dkocher, as stated, the issue is with large files. Please try with uploads >2GB, not a PNG.

@cyberduck
Copy link
Collaborator Author

798541c commented

I enabled debugging defaults write ~/Library/Preferences/ch.sudo.cyberduck.plist logging debug

The debug log is chock full of pretty-private data - client folders, files, usernames, anything transferred that's in the history... basically everything except passwords. Not great at all for sharing online. But I was able to scrub things though, and attached.

The test file name is "Complete performance.mp4".
I believe the "good stuff" is between 18:57:27 and 18:57:57.

Nov  8 18:57:57 MacPro Cyberduck[4362]: [QRLltKrD-transfer-1] WARN  ch.cyberduck.core.worker.AbstractTransferWorker - Failure transferring TransferItem{remote=Path{path='/public_html/xxxxxx/xxxxxx/Complete performance.mp4', type=[file]}, local=Local{path='/Volumes/Barnyard 2 /xxxxxx 2019-09-21/Outputs/Complete performance.mp4'}, lockId='null'}. BackgroundException{file=Path{path='/', type=[directory]}, message='Connection timed out', detail='Read timed out.', class='ch.cyberduck.core.exception.ConnectionTimeoutException', cause='java.net.SocketTimeoutException: Read timed out'}

This would seem to suggest that the issue is not about file size, but lengthy transfers, that get identified as failed & timed out even though they didn't and were successful.

If I'm not mistaken, I canceled the operation at 18:58:36.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Please check the server logs for any reason why it stops responding.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug ftp FTP Protocol Implementation thirdparty Issue caused by third party
Projects
None yet
Development

No branches or pull requests

1 participant