Increment required only when encryption is enabled #28820
Conversation
sharidas
force-pushed
the
fix-errorlogs-encryptionwrapper
branch
from
b3c48db to
3f7dacf
Compare
sharidas
changed the title
|
One reason why we still set the encryption wrapper even when encryption is disabled is mostly because we want to be able to detect formerly encrypted files and avoid sending these back. So if we want to add such bypass we might need to at least put it after the encryption check, which might be when reading the header. |
sharidas
force-pushed
the
fix-errorlogs-encryptionwrapper
branch
from
3f7dacf to
6b62edf
Compare
| @@ -937,9 +943,13 @@ protected function getHeader($path) { | |||
| // if the header was empty we have to check first if it is a encrypted file at all | |||
| // We would do query to filecache only if we know that entry in filecache exists | |||
| $info = $this->getCache()->get($path); | |||
| $encryptionModule = ''; | |||
There was a problem hiding this comment.
Made alterations at the getHeader method. The intention here was to pass encryption module wrapped in array if encryption is enabled. And this value is later used https://github.com/owncloud/core/pull/28820/files#diff-938b56891f3079e628cfda1c331911b7R381 to call different storage's fopen. I hope this is the same header which is mentioned at #28820 (comment)
sharidas
force-pushed
the
fix-errorlogs-encryptionwrapper
branch
4 times, most recently
from
ec8f695 to
dd13bd0
Compare
sharidas
changed the title
|
I see #28780 fixed here. |
sharidas
force-pushed
the
fix-errorlogs-encryptionwrapper
branch
from
dd13bd0 to
a710404
Compare
There was a problem hiding this comment.
👍 code looks fine.
As discussed it would be good to adjust the trashbin tests to verify that the restored file's contents matches before deletion, and have this test run for encryption too (some encryption tests are disabled with trashbin)
Please also retest versions: restoring or downloading older versions of a file must still work on home and external storage
sharidas
force-pushed
the
fix-errorlogs-encryptionwrapper
branch
from
a710404 to
1485064
Compare
Increment to files in filecache is required only when encryption is enabled. Else use the version as it is. Signed-off-by: Sujith H <[email protected]>
sharidas
force-pushed
the
fix-errorlogs-encryptionwrapper
branch
from
1485064 to
98680b0
Compare
|
Verified that transfer ownership works with this change. Verified that upon deletion of the file after transfer, made some update, the versions are restored. |
|
@sharidas please backport to stable10 |
|
Backport : #28880 |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Increment to files in filecache is required only when
encryption is enabled. Else use the version as it is.
Signed-off-by: Sujith H [email protected]
Description
When encryption is not enabled then no need to go through each and every step in encryption wrapper's fopen. Instead we can get another storage wrapper's fopen handler.
Related Issue
#28780
Motivation and Context
This would help resolve the exceptions thrown in the logs.
How Has This Been Tested?
testunder shared folder.testtestfolder from the trashAlso I have noted that during verification on my local machine the storage passes to local storage from the encryption wrapper ( when no encryption is enabled ).
Screenshots (if appropriate):
Types of changes
Checklist: