This is not a solution. High I/O load during every scan and it can take hours depending on your content.
1 Like
well why not trying app inotify? first and then a small routine for scanning only affected folders?
Only affected folders? Anything uploaded via webdav has this problem. And if you have a lot of end users it’s going to be completely random.
You would have to set a cronjob to run a file scan every couple of minutes and let all of your end users know what’s going on.
I personally have over 40TB of content so that’s not going to end well. Will take a very long time to scan.
There is no winning here. It needs to be fixed 
1 Like
i dunno if “it” can be fixed. But I know devs would be happy if you’d chime in to help them… You’re most welcome there.
Where do I create a bounty for nextcloud bugs? Unreal that this bug made it into production on NC19 but mistakes do happen.
Haha the one time I was going to use it. I’ll wait for a fix patiently but yeah the whole file scan thing isn’t a solution for this IMO.
Thank you for taking your time replying though! Appreciated.
1 Like
yesterday on the test server I updated the system to the daily version - and it looks like the problem has been solved.
Today I will test it as soon as I open my eyes wider 
maybe you wanna take a look into the manual about the scan -function?
meaning: you could just scan for unscanned files. maybe this would speed the routine up a bit?
(@Paradox551 maybe worthy for you as well)
You should not use this on production systems.
It looks like a regression in NC 19. This is something you should report to the bugtracker on github. Check out if someone already submitted it, perhaps it was already fixed in the daily version and the patch will be in the next NC 19 release. And it must be fixed in the code, rescanning the folder and stuff like that is just a workaround!
1 Like
@JimmyKater scanning unscanned files is not solution. Files where is 0 zero sized are not unscanned. They have own record in DB table oc_filecache but there is 0 recorded in table in size. In this mode file is not unscanned.
You should read the 1.st post.
But decission has been made already. We have stopped using nextcloud as our cloud storage. Too much bugs and this is the last serious bug not repaired in short time with some patch. So it is crap. Damaging office files has been top. Downgrade impossible without damage.
We migrated all data to concurent.
RIP nextcloud.
Thanks for all answers.
If you need guaranteed response and fix times, you should have looked for enterprise subscriptions. You were not alone with this problem, however it wasn’t a problem for everybody either. So it could be related to some configuration stuff that is difficult to track down.
1 Like
The configuration has not been changed for months. The bug has been involved by 19.0.0 update, what results in mentioned problems with size immediately.
This is an interesting point because the issue on github is older. It’s important but difficult to handle all this information. I hope a developer will help you out soon, perhaps they can add some additional logging at some parts of the code…
I feel like this could have been handled better. I stand by what I said regarding NC 19 being the most stable release in a while (thanks to its long beta period)… but if this was known then webdav should have been disabled and re-enabled in a followup update once fixed.
That’s my only gripe with this issue.
Still not sure why they haven’t done an emergency update to disable webdav for the time being.
1st time coppied file is zero file size. (Inserting into DB is not OK, still insert 0 for the first time)
2nd time coppied and owritten the same file is ok and have proper size. (Updating of DB is properly done, size is OK)
Nextcloud mapped to Z: drive via Webdav Windows 10
Running a LEMP stack with NC19 also has the same odd problem with DB showing 0KB for the file even though it uploaded the full file properly. Very odd and hopefully the devs will fix this bug in 19.0.1 release next week. We often use webdav client RaiDrive for our webdav method for Windows which is more reliable than Windows native webclient.
I second that with 350 users and 50TB of user data. Scanning should be a solution only when importing foreign data from external sources by not going through Nextcloud’s known entry points.
So again.
- Mount nextcloud via webdav (eg. Windows WebClient)
- Copy some file to nextcloud. This results to 0 file size. BUT FILESIZE IS OK ON PHYSICAL NEXTCLOUD STORAGE. In DB is 0. Creating files is not OK. There is no info about files size before inserting to DB.
- Copy the same file again and rewrite the existing file. This results to proper file size in DB. File already exists size is properly updated in DB.
It is connected to process of creating new file and handling the filesize during creation.