-
Notifications
You must be signed in to change notification settings - Fork 799
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
The downloaded file is empty #1946
Comments
Had the same problem! I posted my fix here : |
Same issue on a MAC (Nextcloud Agent Version 3.0.3), NC Server Version: 19.0.4 RCA: Files on Server & Client side are correct. My Workaround to solve the issue:
|
This also happens with Nextcloud client 3.1.3. In my case only some files with the *.txt ending are affected. Renaming them, e.g. to *.text resolves the problem. |
Same isssue. Any updates to solve this issue? |
Still having same issue with german version 21.01 (NC) and Client 3.1.3 on Mac and Windows. The problems seems to affect only files smaller than something like 1 kB and only text format files like txt, xml, etc. my provider is all-inkl.com using php 7.4. Is it possible to change the behaviour of transfering text files to binary mode? |
As far as I can tell the bug is not limited to small files. Downloading these files from the browser also returned files with size 0. Uploading and downloading new files to the directory worked without issues, only existing files were affected. I accessed the files outside of Nextcloud and confirmed that they were intact. Setup: Nextcloud 21.0.1.1 with Docker on Rasperry Pi4, Windows 10 Version 2004 Build 1904.928 and Nextcloud Client 3.2.1 |
@Githopp192 wrote
Is it Okay to have the Client online/connected here?
What if multiple clients are synchronized with the same share? |
As @Simon-Spettmann says, I can confirm too that the bug affects files with any size. Besides that, on my environment seems that only affects to It's weird. Setup
|
@slamora Could you try a more recent version of the client (3.2.1)? |
@FlexW I've updated the client to |
Hi everybody! We have the same issue, but only when accessing .TXT files shared on a remote server. The scenario is the following: Windows Client (3.2.2) -> Nexcloud Server A (21.0.1) -> Nextcloud Server B (20.0.10) User1 shares a folder on server B with User2 on server A. After sync, the error is there for every txt file. |
After a lot of testing I think, that this issue is not directly related to client bugs. Newer clients are only better in error handling, but they also do not download/synchronize the files correctly. Even in the browser TXT files have a 0 byte download size for the affected files. I see the issue only in a federated setup with at least two NC servers. On the NC server which does not have the file copy itself, the unencrypted size is 0 byte for the affected files. The server-to-server synchronization seems to be broken. I also tried to update the Sabre DAV library. This does not solve the issue. |
Maybe this could be caused by some internal process which handles mime types incorrectly, because the built-in web editor can edit the remote txt file, only the donwload is failing, and I can confirm, that renaming the files to .text resolves the issue. Our servers are Apache 2.4 with php 7.4 (running as fpm), Maybe this can be caused by some misbehaving header/mimetype setting in the webserver? |
Saw this with |
This comment was marked as outdated.
This comment was marked as outdated.
This is a bug that makes it unable to use Nextcloud if you use any kind of Not-Binary files like TXT or SVG files. Why does nobody reply to that? It only seems to appear if you share foldes between different servers of nextcloud. I have an installation at german provider All-INKL.com - You can't sync files between different servers of nextcloud if they are .txt or .svp or similar. I have an apache server with PHP7.4 running. |
I see the same issue. Client version: Server version: |
Had this for ages as well I get it propretary text files with not well known extensions (Altium Designer if you want to know) What is odd is the local files do report a size but still generate the message "The download file is empty, but the server said it should have b...." (the rest of the message is trucated in the client) |
Several of you on this thread mentioned the files show as zero bytes in the web browser as well. That suggests to me this is perhaps outside the scope of the desktop client at that point (maybe we need to look at something server-side). The other possibility is you're seeing the same error message in the client, but don't all have the same underlying cause.
|
Josh .. now being on NC 29.0.4, Desktop Agent: 3.13.3 I don't think I've seen the error with the new agents since it last appeared some time ago (maybe years). |
Thanks for getting back to us; since this is a very old issue I will now close it, if it reappears please feel free to reopen |
Expected behaviour
There should be no errors.
Actual behaviour
Desktop client keeps popping up with errors about readme file unable to be synced due to an error. In the client there is an error message: "Readme.md: The downloaded file is empty despite that the server announced it should have been 39 B."
Steps to reproduce
Client configuration
Client version: 2.6.4
Operating system: Windows 8.1
OS language: English
Qt version used by client package (Linux only, see also Settings dialog):
Client package (From Nextcloud or distro) (Linux only):
Installation path of client: C:\Program Files\Nextcloud
Server configuration
Nextcloud version: 18.0.4
Storage backend (external storage):
Logs
Please use Gist (https://gist.github.com/) or a similar code paster for longer
logs.
Client logfile: Output of
nextcloud --logwindow
ornextcloud --logfile log.txt
(On Windows using
cmd.exe
, you might need to firstcd
into the Nextcloud directory)(See also https://docs.nextcloud.com/desktop/2.3/troubleshooting.html#log-files)
The downloaded file is empty despite that the server announced it should have been 39 B.
Readme.md
Web server error log:
Server logfile: nextcloud log (data/nextcloud.log):
The text was updated successfully, but these errors were encountered: