-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore and delete operations in trashbin will affect versions #40291
Conversation
💥 Acceptance tests pipeline webUIUpload-chrome-mariadb10.2-php7.4 failed. The build has been cancelled. |
442b47a
to
a1766e3
Compare
Kudos, SonarCloud Quality Gate passed! |
I don't think I can add unit tests to cover these cases. The files_trashbin app is handling the restoration and deletion of the versions (which is wrong, at least the way it's being done), and core doesn't seem to provide a way to access the versions because they seem to be completely handled by the files_versions app. @phil-davis is it possible to include some acceptance tests to cover these scenarios? Maybe we have better luck using API calls. |
We can try - but I suspect that after restoring or deleting a file from the trashbin, there will be no way to externally access the versions that might be left behind in the trashbin. First we need to try on a current core system to access such "lost" trashed versions with the API. If we can do that, then we can make a test scenario that accesses those, then reverse the checks of those steps (so that they expect the access attempts to fail), then confirm that the test fails on current master, and passes with the code in this PR. I put issue #40286 in out QA automation sprint to get someone to try. |
A test was added in PR #40322 that confirms that versions are restored after a file is deleted and then restored from the trashbin. That is "a good thing" and already works without this PR. We did not find a way to have an end-to-end automated test that verifies that, when a file is deleted from the trashbin, the versions are also deleted from storage and from the database. The existence of versions of a trashbin file seems to be hidden from access via the external API - a user cannot see the versions that might be saved in the trashbin along with a file in the trashbin. So end-to-end tests cannot verify that versions exist in the trashbin, and cannot then verify that the versions are "really" gone when the file is deleted from the trashbin. This is a common challege for any end-to-end test that just accesses an API. On any server that stores persistent data, the data can be verified to exist by accessing it from the API, and checking that the response has the expected data. Then use the API to delete the data, and verify that a GET via the API now returns a "not found". But the server could have only removed the data reference from whatever "database" it uses to know what data items exist. The data might still exist and be taking up space in the persistent storage - there is no way for any "ordinary" end-to-test to know that. |
@jvillafanez how do existing "stranded" version files get cleaned up from the trashbin after someone upgrades to this code? |
I think that those stranded versions come from files within trashed folders. If I remember correctly, deleting or restoring that folder (the one that shows in the root of the trashbin) should fix the issue. |
@jvillafanez lots of code has been merged-back to master with the release of 10.11.0 yesterday. |
de68563
to
4032d73
Compare
77a4f54
to
4032d73
Compare
Kudos, SonarCloud Quality Gate passed! |
Can we get this reviewed and eventually merged, please? Thx. |
can we move this forward? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just hope these function were not "forcefully" used in other apps, as with this change they would brake. just make sure to do quick regex. but change itself looks very legit
@@ -513,14 +513,21 @@ private static function copy(View $view, $source, $target) { | |||
* @throws LockedException | |||
* @throws StorageNotAvailableException | |||
*/ | |||
public static function restore($file, $filename, $timestamp, $targetLocation = null) { | |||
public static function restore($filename, $timestamp, $targetLocation = null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: this is an interface change. See issue https://github.com/owncloud/ransomware_protection/issues/221 and PR https://github.com/owncloud/ransomware_protection/pull/306
We need to adjust the call that is in the ransomware_protection app.
Description
Versions of files were left in the trashbin even though the associated file was either restored or deleted. This causes a performance loss for large scenarios because we have to deal with too many versions while restoring or deleting files from the trashbin.
Related Issue
#40286
Motivation and Context
Versions keep piling up without any chance to clean them up.
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: