[WIP] Delete external storage cache after deletion

[PVince81]

🚧 DO NOT MERGE 🚫

Delete external storage cache entries after deletion.

One issue is that it requires the configuration to be valid. Only with a valid config the Storage instance can be initialized, and only a properly initialized instance will be able to deliver the storage ID that is needed for deletion...

Needs further work.

@icewind1991

[PVince81]

• Issue with misconfigured storages: cannot init/delete them
• "Undo" notification when deleting
• Unit tests

[PVince81]

Depends on #11545 to properly clear the file cache.

[PVince81]

• BUG: renaming mount point deletes + recreates storage which would lose the shares

[PVince81]

Rebased onto master to get the changes from #11694

[PVince81]

Fix for #10820

[PVince81]

@DeepDiver1975 setting this to OC 8.1.

Now that @icewind1991 brought the "stabler" ext storage ids, it might be possible to rename/delete more safely now

[PVince81]

The new "storage_id" is a cool addition, but won't be usable realiable until we fix the endpoints to also work with storage ids. Raised here: #14058

[scrutinizer-notifier]

The inspection completed: 3 new issues, 1 updated code elements

[ghost]

Refer to this link for build results (access rights to CI server needed):
https://ci.owncloud.org//job/pull-request-analyser-ng-simple/9149/
Test PASSed.

[mmattel]

I have two questions:

1. is with this PR also the removal of oc_storages made?
2. If the cleanup is done in oc_filecache and oc_storages, are there any possible leftovers to be taken care for, like shares. eg user 1 shares something with user 2 ect but the storage has been removed.

[PVince81]

1. This PR is for the removal of "oc_storages" entries for external storages that have been deleted in the UI.
   One problem though is that if someone used the "$user" variable in any of the settings, it is likely that a single mount configuration produced multiple "oc_storages" entries, which makes it impossible to find which entries matched the config entry, because so far there is no information in the database that accurately maps ext storage config entries to storage entries (but could be added in the future)
   So for now this PR will focus on deleting the predictable entries (when the magic "$user" was not used).
2. So far there will be possible leftover shares in the database, but they could be cleant up by a future background job, see Delete orphaned shares in a background job #14676

[PVince81]

• raise ticket for complex "$user" case

[mmattel]

#11830 Redesign/revamp oc_storages to fix various issues

[ghost]

Refer to this link for build results (access rights to CI server needed):
https://ci.owncloud.org//job/pull-request-analyser-ng-simple/12077/
💣 Test FAILed. 💣

[ghost]

🚀 Test PASSed.🚀

[PVince81]

Since we still have the storage ids and no proper "mount config to storage id" mapping, we can't reliably delete storage caches.

Deferring to 9.0

CC @Xenopathic

[PVince81]

The underlying code has changed, need to use a different (and hopefully better) approach

[enoch85]

The underlying code has changed, need to use a different (and hopefully better) approach

@PVince81 Is this done yet?

[PVince81]

@enoch85 this is done only for the cases where it is technically possible: as long as you don't use the $user variable in any of that parameters, it will remove the oc_storages and oc_filecache entries of the deleted external storage.

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