nextcloud / desktop

💻 Desktop sync client for Nextcloud
https://nextcloud.com/install/#install-clients
GNU General Public License v2.0
3.05k stars 800 forks source link

The downloaded file is empty #1946

Closed InfamousUser closed 3 days ago

InfamousUser commented 4 years ago

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

  1. Have my PC
  2. Turn it on and notice balloon messages popping up and read error message pinned to the top of the folder tree in Nextcloud client.

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.

  1. Client logfile: Output of nextcloud --logwindow or nextcloud --logfile log.txt (On Windows using cmd.exe, you might need to first cd 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

  2. Web server error log:

  3. Server logfile: nextcloud log (data/nextcloud.log):

jpeg2600 commented 4 years ago

Had the same problem! I posted my fix here :

1993

Githopp192 commented 3 years ago

Same issue on a MAC (Nextcloud Agent Version 3.0.3), NC Server Version: 19.0.4

ScreenShot984

RCA:

Files on Server & Client side are correct.

My Workaround to solve the issue:

bjoernv commented 3 years ago

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.

yuxiang-wu commented 3 years ago

Same isssue. Any updates to solve this issue?

robertskiba commented 3 years ago

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?

Simon-Spettmann commented 3 years ago

Nextcloud Bug - Github

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. The workaround from @Githopp192 seems to work as all files are syncing now without further problems.

Setup: Nextcloud 21.0.1.1 with Docker on Rasperry Pi4, Windows 10 Version 2004 Build 1904.928 and Nextcloud Client 3.2.1 The files are on a remote smb share and everything else worked without any problem. Virtual Files is disabled (for this folder).

bjoernv commented 3 years ago

@Githopp192 wrote

My Workaround to solve the issue: Rename File on Server & Client

Is it Okay to have the Client online/connected here?

Rename File on Server back to original File is now synchronizing to the client compare file and backup-file on client remove backup copy (client)

What if multiple clients are synchronized with the same share?

slamora commented 3 years ago

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 .txt files. As a workaround I've tried to replace the "extension" of the files adding a random one and then they are synchronized! For example, I have renamed foo.txt to foo.txt.hotfix.

It's weird.

Setup

Client: 2.6.5 (Ubuntu)
Server: 20.0.10.1  (Ubuntu Server 20.04.02 LTS)
FlexW commented 3 years ago

@slamora Could you try a more recent version of the client (3.2.1)?

slamora commented 3 years ago

@FlexW I've updated the client to version 3.2.1 and in the meanwhile it's working. I will come back when I have performed more tests. Thanks!

kissthomas commented 3 years ago

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. User2 mounts the share for himself. User2 syncs the new shared folder to his computer.

After sync, the error is there for every txt file. User2 CAN open and edit the text file on server A's web editor! User2 CAN NOT download the text file from server A's website. User2 CAN NOT sync the file content with desktop sync app.

bjoernv commented 3 years ago

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.

kissthomas commented 3 years ago

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?

mcnesium commented 3 years ago

Saw this with .json and .svg files on desktop client v3.1.3, server v21.0.2 Upgraded client to v3.2.1, now I do not see it :+1:

github-actions[bot] commented 3 years ago

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

robertskiba commented 3 years ago

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.

dobos commented 2 years ago

I see the same issue. Client version: Nextcloud version 3.3.6-20211028.151202.6d3270dd2-1.0~focal1

Server version: 20.0.13

the-moog commented 2 years ago

Had this for ages as well Client Version 3.3.6 (Windows) Server Version 21.0.4 (Linux)

I get it propretary text files with not well known extensions (Altium Designer if you want to know) e.g. .BomDOC .OutJob .Dat to name but a few. I have hundreds of them every day.

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)

joshtrichards commented 2 months ago

Even in the browser TXT files have a 0 byte download size for the affected files.

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.

Githopp192 commented 2 months ago

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).

claucambra commented 3 days ago

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