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