Can you add this information to the github issue. Donāt forget to mention the version numbers of server and client. Since this happened recently, can you check your server logfiles to pin-point when this actually happened?
For what itās worth, I see many 0 byte files on my system that are uploaded only by the Android Nextcloud app (fairly up to date). I can imagine instances where the image gets queued for upload, then the image is deleted before a wifi connection is available, so the upload fails but there is a 0 byte placeholder (just a theory, no evidence to back that up).
Other 0 byte files I see are .nomedia files and some various cache, which are legitimately 0 bytes.
Iāve been using NC since the OC 8 days, with the old OC Windows/Linux desktop client and have not seen any 0 byte files coming from there interestingly enough.
It was that if you put a new file, it uploads a file and each file has a file-id. On the server you have the file-id in the main database and the client has a local one where changes are tracked and if there are updates, the files are transferred again.
ownCloud implemented a feature with checksum tests but I think it was only to verify that the transfer finished correctly. So you would still need to sync the files a first time, you canāt just put the file manually and the client would compare the checksums and say itās the same file. Iām not sure if this feature was backported to Nextcloud (it wasnāt available in NC 12 and there were issues when people migrated from oC) and I donāt know if this is planned. Also ownCloud is currently testing a delta-sync. Nextcloud was not very active in the desktop client development but this is changing a bit since they plan to implement client-side encryption: Desktop client has less releases and is behind master
As i understood your posting @tflidd, the nextcloud desktop sync client does not have a crc check and that is the reason why some files have a filesize of 0 bytes after the initial upload by the client.
After an initial upload they shouldnāt have the size 0 (unless the files are really empty). But if there is an error during the upload process that results in 0-sized files, that could be a reason, yes.
Iām also seeing lots of files initially show the correct size then revert to 0kb file sizes. Iām not using the sync client but adding files directly using WebDav via MountainDuck. MountainDuck mounts resources as physical drives on your PC / Mac, and can even do this with Rackspace cloud files etc. So the issue is unlikely to be with MountainDuck but the NextCloud server itself.
MointainDuck seems to be a quite capable and convenient tool. But even if you donāt have anything to hide, isnāt it a problem, if metadata could be transferred to the proprietary and non-open-source software manufacturer? Because maximum autonomy is one one the great features of Nextcloud. On the other hand, Win and Mac are proprietary as well
Itās April 16, 2020 whit this thread being 2 years old and Iām experiencing this problem on a fresh install with the latest client and server. Going to dig a bit further on this issue as this was the first result google returned for me. This is a HUGE issue and basically makes the product useless for production use. Way too risky to maybe have your files synced and accessible.
Sure it is a serious issue but not easy to track as you can see in this issue. There is a related bug report, so it is better to track it down with the developers because they eventually have to look into this: https://github.com/nextcloud/server/issues/3056#issuecomment-274770918
The latest comment seems to get them back on track of this issue.
I wasnāt really bothered by it since (at least on data actively used), but I have to investigate again and report back.
Actually, that is a very good starting point if we look for a way to reproduce this reliably. Many have older systems where itās not really known when it happened, some things might date back to very old version etc. But the bug tracking itself should be on github, so if you can share more details there would be great.
Here are my observations from further testing. The NC client installed on my MacOS (latest version with security updates and Norton Internet security) incorrectly reported āgreen check marksā in the Finder synce folder. Thinking it was finished, there was still transfer activity in the background that wasnāt obvious. Even down in the sub directories I was transferring, there was a green check mark telling me it was synced. I suspect the zero byte files are āplace holdersā for the upload process similar when you have a *.part when downloading in Firefox.
Before I discovered the above, I copy/pasted some test folders that were previously zero bytes. They immediately became available and could be opened ā much faster than a re-upload could provide. This seemed to kick off the rest of my transfers.
This issue (for me) seems to only happen when I try to transfer a larger number of files. 10GB of photos. So I echo what others have stated on this.
I setup a second NC server (Ubuntu 18.04 / latest stable NC) within my home LAN. I tested transferring the same data set. While I had different syncing issues, My data correctly synced in the background. (transferring pics from the iPhone photo gallery using the NC auto sync feature).
I suspect that the NC client is having issues with my basic Godaddy shared web hosting. I have the Linux Deluxe account with shell access with them.
Also noticed that in my bulk file transfer, the job returns an error in the client when it hits files ~25mb + ā āserver replied 503: service unavailableā. My internet connection is rock solid and suspect that Godaddy shared hosting doesnāt like me syncing a large amount of files in this way as GD package I got wasnāt meant to be a dropbox like replacement. While the sync job reports as finished again by the NC client, it seems to still be going as I am getting MacBook popup notifications.
Update:
My initial / baseline sync seems to have completed. About 10 GB of photos and documents. I can now see the documents via web browser and the files are reporting sizes. I am almost certain that the issue I am facing and perhaps others is the way the local NC client is reporting job completion. At first, the NC client was reporting zero byte and job completed when hiding in the background it was still uploading files. Looking at the NC client folder list, they show a green check (like dropbox) when the folder is synced but the NC client has yet to upload the filesā¦ so I assume itās some sort of lock file during the sync/upload process. Now after a few days of running, the files seem to have synced and I can see them now checking in the browser for the images to load that Iāve uploaded. So the files are there, but now the NC client is still reporting āzero filesā beside the folder (for file count and not byte size this time) So as far as I see, the files are there and synced now, the client is not updated.
So all this to say, I believe the issue maybe two fold.
My shared godaddy hosting account (linux deluxe with ssh) has some crappy performance and perhaps some throttling / resource limitations that is causing some slow connection issues that the NC client might be choking on.
The way in which the NC client verifies / refreshes sync actions is not getting refreshed properly and/or in a way that is intuitive.
Iām very very new to using NC so consider me looking at this issue with a brand new set up customer eyes that may reflect a larger new comer experience.
I absolutely love the NC product and itās awesome that it is free. (thank you) I just hope the devās take note of these issues and work out this bug. I saw the new release in beta advertised with an ubuntu 20.04 server. So I am excited to see what has been improved.
Devās: feel free to reach out for more info, Iād be happy to help your cause. Iām an IT guy.
On hosted accounts there is sometimes some strange behaviour. If you set up a server yourself, you should check the configuration in the documentation to make sure everything runs properly and improved cache settings increase the sync performance dramatically. On shared hosting, you donāt have access to it at all and some configuration settings can harm the performance. And itās hard/impossible to debug.
I just hit the same issue, latest NextCloud running in Docker, with the latest Windows client.
I transferred a bunch of larger files amounting to ~130GB in total, and 2 of the larger files are 0 bytes. I got a bunch of 503 errors during upload in the client, so it restarted, 503 again, restarted, and so on for several hours. Finally finished, and now Iām left with 0 byte files.
Iāll mark this as solved in the forum. There seems to be a bug somewhere and it has to be discussed with the developers how to find and fix this issue. Please contribute there if you can:
Hi,
I realize I have the same problem. Some files are ok but some have written kb, but in fact are corrupted (in fact empty or un-openable in software).
It seems on github issues itās related to 504 error during upload, which I experimented a lot. In the meantime developpers solved the problem, does it have a way to force re-sync all files from client without unlink everything and restart from scratch? BTW, just clicking āforce synchronizationā doesnāt work, since NC thinks all the files are correctly synced to the server.
Thanks
