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
Chunked downloads result in zero sized file #7933
Comments
I don not understand and cannot reproduce the issue.
It might be a server issue if the content is advertised to be compressed over the wire but is in fact sent as plain text. |
Replying to [comment:1 dkocher]:
Could you please clarify which point you don't understand ?
Note that it works well with other clients like s3cmd, DragonFly, so this tend to exclude the "server side" issue, don't you agree ? |
Hello Dkocher, I forget to give this info when the download fail : the file is created localy, but is empty. Still looking for a possible resolution of this issue, and I would like insist on facts that the download with other largely used s3 clients (s3cmd and DragonDisk) works well, so everything makes think that there is a problem with CyberDuck on at least my context at the download or file creation on my disk. I plane to check my drive and do the same test on a Windows platform, will let you inform. It would be great if you can try to reproduce it or at least give me some pointers that could help ? Cheers, Cédric |
Replying to [comment:3 dafresh]:
Thanks for the additional information. There is an issue with transfers not taking place when the |
Good news. It seems it is related with my previous opened case #7906, I think I need to improve a bit my "reporting skill". Thanks for the great works, Cédric |
Hello, Issue seems still present with 394e8c1. Thanks ! |
I confirm, works with 1eaacb5 . Thanks ! |
Hello,
I discover that when a .txt file is uploaded to a S3 bucket, CyberDuck cannot download it back, but it workds fine with s3cmd.
Headers defined on the .txt files at the upload seems to be :
For info "file" cmd on Mac determines it as " UTF-8 Unicode text".
A workaround to download back the file is to :
Except if I miss something, it seems there is a glitch with some files type and associated headers ;-)
On the other hand, why Content-Encoding is defined to "gzip" ?
Cheers,
Cédric
Attachments
download.log
(1.6 KiB)upload.log
(1.5 KiB)The text was updated successfully, but these errors were encountered: