Increment required only when encryption is enabled

[sharidas]

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?

• Create external storage with SFTP
• Create a folder test under shared folder.
• upload a file under test
• Delete the test folder
• Try to access the test folder from the trash
• No exception logs found

Also 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

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[PVince81]

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]

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)

[SergioBertolinSG]

I see #28780 fixed here.

[PVince81]

👍 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

[SergioBertolinSG]

Integration tests part is ok

[sharidas]

Verified that transfer ownership works with this change. Verified that upon deletion of the file after transfer, made some update, the versions are restored.

[PVince81]

@sharidas please backport to stable10

[sharidas]

Backport : #28880

[lock]

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.