Properly handle encrypted/plain file size with object storage

[juliusknorr]

When using primary object storage we store the size of the bytes written to the storage in the file cache. Since the filecache is reused for the stat call, fetching the file size will lead to the encrypted size being returned in https://github.com/nextcloud/server/blob/master/lib/private/Files/Storage/Wrapper/Encryption.php#L494 instead of the unencrypted one as it would be the case for local storage. Now the filecache has a column unencrypted_size which seems to be never used actually. This will actually cause https://github.com/nextcloud/server/blob/master/lib/private/Files/Storage/Wrapper/Encryption.php#L526 to be called with both size and unencryptedSize being the same, the encrypted size.

While we could go though the whole file to check the signature on the last block this has quite some performance impact, so we'd need a way to either make sure that the unencrypted size is put into the size column (as it is currently done for local storage) or better use the unencrypted_size in general to store this.

Steps to reproduce:

• primary object storage
• upload a file
• download it
• download it again to encounter a bad signature exception

cc @rullzer

[J0WI]

Related to #10767 #16906 #22077 #17561
Not sure if owncloud/core#26917 would help here?

[szaimen]

Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!

My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!

If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+

[juliusknorr]

Fixed by @icewind1991 recently.