Files become zero bytes

It seems like the upload procedure from the Client can destroy the Files on the Server.

Wonder if another Client, for example a Combination of webdav mount and rsync, would make less Work than finding the Problem.

If it helps, I personally use a mix of Android client, webDAV permanently mounted, and SSHFS. The latter only because I interface my data via the external storage app to avoid having problems accessing the data locally via filesystem.


Well, i have again a brand new installation of NC 13 and the desktop client 2.3.3 build 1 on Windows 10. So the bug occured two times in the last days.

I’m just filling up the NC server with data and before it goes live i check if some zero files were created. This is a must i believe. Otherwise maybe i can’t restore the zero-file anymore.

But then you don’t have a copy of your files on your workstation.

Doing rsync on the webdav could solute this.

After Reading of the Zero Byte Problem, i also found this at my Server. I really Need a sync solution so either i find an alternative of the nextcloud sync or I find an alternative to the whole nextcloud.

For me,An alternative to nextcloud sync could be using webdav. And downloading it on some PCs AS an Backup, one-directional. This also saves Space and sync time on the clients.

But I am very afraid - the 0 Byte Problem is a very very big Problem that exists in both paid and free owncloud and free nextcloud. But noone found a solution and not really much people even seem to Know about.

This is Something that should let me drop the usage of nextcloud.

That has literally never been an issue. Nor have I ever needed the Dropbox/box/GDrive clients either though so YMMV

There are other sync clients that can be used IIRC. I’ll have a dig around.

Ok, it still is an open topic, I reopened the topic on github again. I have never seen data loss myself, but I started to look for empty files on my own setup. Some are just locking-files or temp-files a lot in the trash bin. There are however a couple of actual files that are 0-size (also on the synced client). i will see in the next couple of days, if I can track that down somehow.

@JasonBayton: You haven’t seen this problem, so this could be a good indicator that this is actually the client?

I’d say so, yes.

1 Like

Do you Know Any alternative to the Client? Would a rsynced webdav be a good Idea?

And maybe, could all Users Post the Last Change Date of the Zero Byte Files? So for example If they all are 2017/2018, You will quickly See in what Version of the Client the Problem occured First.


I did some further research and updated as well the github issue

"Update after some research:

I must correct that I only really lost two files to 0 but was able to recover them from a backup.

These two files may be from an older sync executed with an old windows NC client around end of 2016 / beginning of 2017. The other 0-ed files were either really empty (text files not really used) or were in one of these directories, which didn’t really bother:

Some files:

And some folders:

So this may really be related to a problem we had with a much older windows client. Sorry for the alarmism from my side."

I am using the latest nextcloud Server Forum Ubuntu 18.04 and the latest nextcloud Client for Ubuntu 18.04. both installed two weeks ago.

The Zero File bug occured anyway. So I dont think that relies to an old client.

1 Like

So your affected files are from the past two weeks? Because for me besides the two older files it seems ok. NC Clients: Win7 / Deb 9.x

I never Used nextcloud before. I migrated from Google two weeks ago after Testing nextcloud vor two weeks. After that two weeks, i reinstalled the whole VM with all actual versions.

But I only use the Ubuntu sync Client. Maybe the Error was corrected in the Windows Version, but Not in the Ubuntu Version

Hmmm… ok.

So what does this one results for you in a bash on the server (-v to exclude updater dir):

find ./yournextcloud/data/ -size 0 -type f | grep -v updater | wc -l

and general
find ./yournextcloud/data/ -size 0 -type f | grep -v updater

I did this to recognize that some PDF were corrupted

I once thought having a problem with german umlauts (ä ö ü). Do your pdfs have some of them?

Ja :slight_smile:

Much of the 0 Files were Files that contain ä ö ü ß / _&-+ in the Filename. But There also was an output.pdf for example.

PS: kann es sein dass sich hier fast ausschließlich deutschsprachige völlig umsonst mit dem Versuch abmühen, einigermaßen Englisch zu sprechen?

Well - it could indeed be like this, I do also speak German :slight_smile:

But I think it’s quite important writing in English, as it allows plenty of users to get the most out of troubleshoot postings.

Coming back to your problem - it’s possible there’s a thing with sonderzeichen and language packs whatever. Maybe some devs could make their opinion about this.


Yeah but as i Said… Some Files were Just random. But Sonderzeichen (what is it in english?) Is a typical Problem.

What Makes me scared: nearly everybody that was asked to Look for 0 Byte Files finds some. Nearly Everybody that uses the sync Client. Also at owncloud.

So it seems Like nearly every nextcloud and owncloud User is losing Data.

Thats scary on the one hand- but how can it be that nearly noone recognizes the Data loss without mention? Do the Data someday reappear?