Add command to remove obsolete storages from the filecache

[jvillafanez]

Description

Provide an occ command to remove obsolete storages from the DB. The command is limited to the oc_storages and oc_filecache tables.

The recommended action plan is:

1. Remove the mount point configuration from the web UI.
2. Access to the oc_storages table and check which storages aren't used any longer.
3. Run the occ files:remove-storage command with those storages.

In case the storage is still in use, a new storage id is likely to be assigned, and you'll need to rescan the storage. This also means that the clients will think the files are new and they'll download the files.
Anyway, the files won't be touched in the backend.

Related Issue

https://github.com/owncloud/enterprise/issues/5630

Motivation and Context

This will help to keep the DB more tidy by removing entries that won't be needed any longer. It will also help with the performance because the dataset will be reduced

How Has This Been Tested?

Manually tested

1. Setup an external storage with a bunch of files in it
2. Run an occ files:scan to bring the data into the DB
3. Remove the external storage using the web UI
4. Check the numeric storage id for the storage in the DB
5. Run the files:remove-storage command with the target storage id

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Database schema changes (next release will require increase of minor version instead of patch)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:
• Changelog item, see TEMPLATE

@mmattel for documenting the command when it's merged

[jvillafanez]

I don't think I can add unit tests... mocking the connection is complex. The other option is to access to the DB, but we need a way to fill the data, which means we need to use additional components.

[mmattel]

Check the numeric storage id for the storage in the DB

This is imho a very bad idea...
How does one be able to identify the ID? Fiddling in the database is not good.
It would be better to internally get all possible ID's, and check which ones to have a mount point entry and print the result via a --dry-run option. Finally one can run teh command using an ID which was formerly printed.

for documenting the command when it's merged

We could directly add the description when the command is final to this PR making it available immediately. I can support, but coding should be finished.

[jvillafanez]

We can provide a way to list the potential unused storages, but there could be storages wrongly marked as unused (some extra info in https://github.com/owncloud/enterprise/issues/5630#issuecomment-1540375335). Fully automating the process seems too risky, so I think it's better to delegate the final decision to the admin.

We also need to decide which relevant info we want to show to the admin. The numeric id of the storage won't tell anything, and the storage id could be hashed. I don't find any relevant info we could use to help the admin to decide which storage he wants to delete.

[mmattel]

@jvillafanez If ok to you:

• I would add a commit to describe the new occ command
• As you have written in the referenced issue:
  It could also break things if ownCloud is actively using it.
  Shall I add a note to run this command in single user mode?

[jvillafanez]

Yes, feel free to adjust the description.

Shall I add a note to run this command in single user mode?

As a recommendation it's a good thing to have. I mean, assuming you're targeting the right storage, single user mode shouldn't be needed because nobody should be using that storage; the problem is if you target a wrong storage.

[jvillafanez]

Still need to test with postgresql and oracle. Hopefully no changes are needed

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
20 Code Smells

0.0% Coverage
0.0% Duplication

[mmattel]

@jvillafanez Mind to post an example of --show-candidates if you have one?

[jvillafanez]

occ files:remove-storage --show-candidates
+---------+-------------------------------------------------+------------+
| storage | id                                              | file_count |
+---------+-------------------------------------------------+------------+
| 3       | local::/mnt/data/files/                         | 3          |
| 12      | wnd::MOUNTAIN\mountainUser1@10.0.2.203/foobar// | 9          |
| 15      | NULL                                            | 8          |
+---------+-------------------------------------------------+------------+

The id could be null (as shown) if there is no info about it in the "oc_storages" table. It could also be hashed if it's too long (as it is in the DB)

[mmattel]

• Q: why does wnd::MOUNTAIN\mountainUser1@10.0.2.203/foobar// have a double // at the end? looks strange to me, but may be ok.
• Reading the exampe output, we should imho rename the columns:
  • storage --> storage-id to comply with the command argument.
  • id to something like name to avoid confusion.

[jvillafanez]

Q: why does wnd::MOUNTAIN\mountainUser1@10.0.2.203/foobar// have a double // at the end? looks strange to me, but may be ok.

That's part of the id of the storage. It could be nicer, but it is what it is.

I'll adjust the headers

[jvillafanez]

I'm having problems to connect to an oracle DB, so the PR is currently untested with oracle. Worst case, the command won't work. I don't expect bigger issues.
The PR should work with postgresql with the last commit.

[jvillafanez]

Tested with oracle, works now.

Columns names are changed now as requested:

occ files:remove-storage --show-candidates
+------------+---------------------------------------+------------+
| storage-id | name                                  | file_count |
+------------+---------------------------------------+------------+
| 3          | local::/mnt/data/files/               | 2          |
| 9          | wnd::WORKGROUP\ubuntu@10.0.2.27/opt// | 54         |
+------------+---------------------------------------+------------+

[mmattel]

@phil-davis @pako81 mind to support with a review, I cant as my oc server dev env is down atm.
From that what I read it looks good to me. SonarCloud needs to get happy somehow...

[phil-davis]

The code looks OK to me.
In my local dev setup I get:

$ php occ files:remove-storage --show-candidates
+------------+-------------------------------------------+------------+
| storage-id | name                                      | file_count |
+------------+-------------------------------------------+------------+
| 4474       | local::/home/phil/git/owncloud/core/data/ | 9          |
| 10000      | NULL                                      | 1          |
+------------+-------------------------------------------+------------+

Then I did:

$ php occ files:remove-storage 10000
 1/1 [============================] 100%
$ php occ files:remove-storage --show-candidates
+------------+-------------------------------------------+------------+
| storage-id | name                                      | file_count |
+------------+-------------------------------------------+------------+
| 4474       | local::/home/phil/git/owncloud/core/data/ | 9          |
+------------+-------------------------------------------+------------+

My real data dir is shown in the list. That makes me a bit nervous - I don't want to remove the real data dir that has users and some file. Is that "normal" that this command can show the real local data dir?

I didn't try removing 4474 - hopefully something will stop me if I do???

[jvillafanez]

I agree the data directory shouldn't appear, but I don't think we can easily exclude it. There is no user mounting that (and there shouldn't be), so that's why it appears.

I didn't try removing 4474 - hopefully something will stop me if I do???

There is no safety net.

For whatever reason, there is a view with the data directory as root, and that's why it appears in the filecache. We probably should use a custom access to the data directory so the data doesn't end up in the filecache. It seems too late to do that.

Worst case, I think only the data in the filecache will be removed. The actual files in the FS will remain. I expect the data to reappear at some point. In addition, I think it usually has few files, so removing it isn't probably worthy.

[phil-davis]

I tried removing it:

$ php occ files:remove-storage --show-candidates
+------------+-------------------------------------------+------------+
| storage-id | name                                      | file_count |
+------------+-------------------------------------------+------------+
| 4474       | local::/home/phil/git/owncloud/core/data/ | 9          |
+------------+-------------------------------------------+------------+
$ php occ files:remove-storage 4474
 9/9 [============================] 100%

Then 10 seconds later:

$ php occ files:remove-storage --show-candidates
+------------+-------------------------------------------+------------+
| storage-id | name                                      | file_count |
+------------+-------------------------------------------+------------+
| 6758       | local::/home/phil/git/owncloud/core/data/ | 8          |
+------------+-------------------------------------------+------------+

And I can still login as the users that are on my dev system, and their files still exist. I am not sure why file_count is now 8 and not 9. But anyway, doing this "dumb thing" has not destroyed my system.

[mmattel]

Note that the corresponding documentation PR contains the following text as IMPORTANT tag:

This command should be handled with absolute care because *any* storage ID and the correlated file cache can be removed. For safety reasons, the following advices are given:
* Switch to single user mode.
* Make a backup of the database first.
* To identify removal candidates, run this command with option `--show-candidates` first.

I think that anyone using that command got notified, reading the docs first of course.

[phil-davis]

LGTM. Manually tested (see comments in the PR).

[mmattel]

CI is green except sonarcloud - how to proceed? (force merge?)

[phil-davis]

SonarCloud is not a "required" result. We can ignore that, since we agree that unit test coverage is difficult for this command. It's fine to merge from my PoV. Who else needs to review and agree to this?

[pako81]

Going to review this and start manual testing in a while.

[pako81]

Manual tests seem to be ok 👍

Tested with both auth methods: Log-in credentials, save in session and Log-in credentials, save in database --> relevant entries are correctly removed from the oc_storages and oc_filecache tables.

One small remark: the entry related to the user creating the mountpoint over the Web UI (admin in my case) is not removed upon running the command:

MariaDB [core]> select * from oc_storages where id like '%wnd%';
+----------------------------------+------------+-----------+--------------+
| id                               | numeric_id | available | last_checked |
+----------------------------------+------------+-----------+--------------+
| wnd::admin@xx.xxx.x.x/leomessi// |          4 |         0 |   1685531448 |
+----------------------------------+------------+-----------+--------------+
1 row in set (0.000 sec)

Not a big issue I would say as there are anyway no orphaned oc_filecacheentries pointing to this storage id.

[pako81]

Let's merge this?

[phil-davis]

I suppose this will be released in the normal flow of 10.13 release.

[pako81]

I suppose this will be released in the normal flow of 10.13 release.

correct.

[cdamken]

Using it does not do a next line:

root@snoopy4:/var/www/owncloud# occ files:remove-storage 1037
 107031/107031 [============================] 100%root@snoopy4:/var/www/owncloud# occ files:remove-storage 1000
 1/1 [============================] 100%root@snoopy4:/var/www/owncloud# 

[cdamken]

But I cleaned a lot:

+------------+------------------------------------------------------------+------------+
| storage-id | name                                                       | file_count |
+------------+------------------------------------------------------------+------------+
| 3          | local::/mnt/owncloud/data/                                 | 55991      |
| 421        | local::/tmp/uploads/wacanhca/                              | 1          |
| 423        | local::/tmp/uploads/pastripodi/                            | 1          |
| 424        | local::/tmp/uploads/compl4xx/                              | 1          |
| 425        | local::/tmp/uploads/aries-server/                          | 1          |
| 426        | local::/tmp/uploads/svanber/                               | 1          |
| 427        | local::/tmp/uploads/Robert-a-gaudin@t-online.de/           | 1          |
| 429        | local::/tmp/uploads/Alex/                                  | 1          |
| 430        | local::/tmp/uploads/Angeles/                               | 1          |
| 432        | local::/tmp/uploads/Carolin/                               | 1          |
| 433        | local::/tmp/uploads/JhonLinx/                              | 1          |
| 435        | local::/tmp/uploads/Leticia/                               | 1          |
| 436        | local::/tmp/uploads/MMontiel/                              | 1          |
| 437        | local::/tmp/uploads/Maysun/                                | 1          |
| 438        | local::/tmp/uploads/Poiware/                               | 1          |
| 440        | local::/tmp/uploads/Steffen/                               | 1          |
| 441        | local::/tmp/uploads/adri_ilea/                             | 1          |
| 442        | local::/tmp/uploads/agata/                                 | 1          |
| 443        | local::/tmp/uploads/albeip/                                | 1          |
| 445        | local::/tmp/uploads/alexaries/                             | 1          |
| 446        | local::/tmp/uploads/alfageme/                              | 1          |
| 448        | local::/tmp/uploads/bolilloman/                            | 1          |
| 449        | local::/tmp/uploads/castle_ghost/                          | 1          |
| 452        | local::/tmp/uploads/daniel/                                | 1          |
| 453        | local::/tmp/uploads/dgonzalez/                             | 1          |
| 455        | local::/tmp/uploads/felix.heidecke/                        | 1          |
| 456        | local::/tmp/uploads/haukman/                               | 1          |
| 458        | local::/tmp/uploads/ikozar/                                | 1          |
| 459        | local::/tmp/uploads/ineumann/                              | 1          |
| 462        | local::/tmp/uploads/kasondofuc/                            | 1          |
| 463        | local::/tmp/uploads/konisolde/                             | 1          |
| 465        | local::/tmp/uploads/maxkocher/                             | 1          |
| 467        | local::/tmp/uploads/ornorieg@gmail.com/                    | 1          |
| 468        | local::/tmp/uploads/password/                              | 1          |
| 469        | local::/tmp/uploads/rafaeldamken/                          | 1          |
| 472        | local::/tmp/uploads/romaxombie/                            | 1          |
| 476        | local::/tmp/uploads/settermjd/                             | 1          |
| 479        | local::/tmp/uploads/svetansson/                            | 1          |
| 480        | local::/tmp/uploads/tboerger/                              | 1          |
| 481        | local::/tmp/uploads/tpn/                                   | 1          |
| 483        | local::/tmp/uploads/villava/                               | 1          |
| 485        | local::/tmp/uploads/zempoalteca/                           | 1          |
| 493        | local::/tmp/uploads/test/                                  | 1          |
| 497        | local::/tmp/uploads/yoljconde/                             | 1          |
| 499        | local::/tmp/uploads/daw/                                   | 1          |
| 504        | local::/tmp/uploads/matthias/                              | 1          |
| 505        | local::/tmp/uploads/Jimmy77828/                            | 1          |
| 510        | local::/tmp/uploads/koni/                                  | 1          |
| 514        | local::/tmp/uploads/Tool12/                                | 1          |
| 516        | local::/tmp/uploads/pablo/                                 | 1          |
| 518        | local::/tmp/uploads/crodriguez/                            | 1          |
| 521        | local::/tmp/uploads/dschmidt/                              | 1          |
| 523        | local::/tmp/uploads/fstocker/                              | 1          |
| 529        | wnd::carlos@10.1.10.113/carlos//                           | 2          |
| 544        | local::/tmp/uploads/lbr/                                   | 1          |
| 546        | local::/tmp/uploads/lizzardts/                             | 1          |
| 556        | local::/tmp/uploads/demetrio/                              | 1          |
| 559        | local::/tmp/uploads/Angel A/                               | 1          |
| 561        | local::/tmp/uploads/CWNUE/                                 | 1          |
| 564        | local::/tmp/uploads/Netmage/                               | 1          |
| 568        | local::/tmp/uploads/Markus/                                | 1          |
| 570        | local::/tmp/uploads/mbarz@owncloud.com/                    | 1          |
| 576        | local::/tmp/uploads/AlexA/                                 | 1          |
| 580        | local::/tmp/uploads/m.rode/                                | 1          |
| 590        | local::/tmp/uploads/OWN/                                   | 1          |
| 592        | local::/tmp/uploads/taiyang/                               | 1          |
| 594        | local::/tmp/uploads/lalejlazawan/                          | 1          |
| 603        | local::/tmp/uploads/Toledano/                              | 1          |
| 605        | local::/tmp/uploads/lukashirt/                             | 1          |
| 621        | local::/tmp/uploads/davidslaughter/                        | 1          |
| 623        | local::/tmp/uploads/sham0197929921@gmail.com/              | 1          |
| 625        | local::/tmp/uploads/guruz/                                 | 1          |
| 630        | local::/tmp/uploads/munim/                                 | 1          |
| 634        | local::/tmp/uploads/gboegerl/                              | 1          |
| 636        | local::/tmp/uploads/iwurzer/                               | 1          |
| 638        | local::/tmp/uploads/skarakaya/                             | 1          |
| 640        | local::/tmp/uploads/juan.orozco/                           | 1          |
| 644        | local::/tmp/uploads/mwenzel/                               | 1          |
| 649        | local::/tmp/uploads/testing001/                            | 1          |
| 651        | local::/tmp/uploads/marek/                                 | 1          |
| 655        | local::/tmp/uploads/domifry/                               | 1          |
| 657        | local::/tmp/uploads/kokonis/                               | 1          |
| 659        | local::/tmp/uploads/alicis/                                | 1          |
| 669        | local::/tmp/uploads/Juan/                                  | 1          |
| 671        | local::/tmp/uploads/Gusasus/                               | 1          |
| 673        | local::/tmp/uploads/Exporter/                              | 1          |
| 675        | local::/tmp/uploads/ziemjavier@hotmail.com/                | 1          |
| 677        | local::/tmp/uploads/matiasmasca/                           | 1          |
| 679        | local::/tmp/uploads/leito_zt/                              | 1          |
| 683        | local::/tmp/uploads/facuq240/                              | 1          |
| 688        | local::/tmp/uploads/alloariasjl75@gmail.com/               | 1          |
| 693        | local::/tmp/uploads/imagenes/                              | 1          |
| 696        | local::/tmp/uploads/Mazerazer/                             | 1          |
| 698        | local::/tmp/uploads/Rainer/                                | 1          |
| 701        | local::/tmp/uploads/quimono/                               | 1          |
| 703        | local::/tmp/uploads/Sharjah/                               | 1          |
| 706        | local::/tmp/uploads/Julius/                                | 1          |
| 712        | local::/tmp/uploads/davigonz/                              | 1          |
| 714        | local::/tmp/uploads/jebm20/                                | 1          |
| 716        | local::/tmp/uploads/jhonsharedmx/                          | 1          |
| 723        | local::/tmp/uploads/Aki/                                   | 1          |
| 725        | local::/tmp/uploads/dn-claudia@web.de/                     | 1          |
| 727        | local::/tmp/uploads/jason.bartz.gr/                        | 1          |
| 729        | local::/tmp/uploads/AlexAries/                             | 1          |
| 731        | local::/tmp/uploads/Alejandra/                             | 1          |
| 741        | local::/tmp/uploads/fvaldivia88/                           | 1          |
| 751        | local::/tmp/uploads/ariesingenieriaintegral/               | 1          |
| 761        | local::/tmp/uploads/lol_brossier/                          | 1          |
| 771        | local::/tmp/uploads/Flaan4me/                              | 1          |
| 777        | local::/tmp/uploads/s.aaron.h88/                           | 1          |
| 783        | local::/tmp/uploads/Mrmonk/                                | 1          |
| 786        | local::/tmp/uploads/Leonardo/                              | 1          |
| 789        | local::/tmp/uploads/manuel/                                | 1          |
| 791        | local::/tmp/uploads/matthias@owncloud.com/                 | 1          |
| 804        | local::/tmp/uploads/csf/                                   | 1          |
| 811        | local::/tmp/uploads/zygsodsystem/                          | 1          |
| 813        | local::/tmp/uploads/dmelis/                                | 1          |
| 817        | local::/tmp/uploads/rusbus71@hotmail.com/                  | 1          |
| 825        | local::/tmp/uploads/Hafid/                                 | 1          |
| 827        | local::/tmp/uploads/Hafid.abc4/                            | 1          |
| 833        | local::/tmp/uploads/aouerghui/                             | 1          |
| 835        | local::/tmp/uploads/navioltip/                             | 1          |
| 837        | local::/tmp/uploads/secureview-test/                       | 1          |
| 845        | local::/tmp/uploads/Paulis/                                | 1          |
| 847        | local::/tmp/uploads/taki1st3011@gmail.com/                 | 1          |
| 851        | local::/tmp/uploads/jrs/                                   | 1          |
| 857        | local::/tmp/uploads/Helson D./                             | 1          |
| 859        | local::/tmp/uploads/erodri2k1/                             | 1          |
| 861        | local::/tmp/uploads/juewei/                                | 1          |
| 863        | local::/tmp/uploads/jamu85/                                | 1          |
| 867        | local::/tmp/uploads/Leini/                                 | 1          |
| 869        | local::/tmp/uploads/Leini69/                               | 1          |
| 871        | local::/tmp/uploads/brunhild.bakker@gmail.com/             | 1          |
| 873        | local::/tmp/uploads/Raphael Peters/                        | 1          |
| 877        | local::/tmp/uploads/jcortez/                               | 1          |
| 880        | local::/tmp/uploads/jrsm/                                  | 1          |
| 883        | local::/tmp/uploads/kaion/                                 | 1          |
| 888        | local::/tmp/uploads/mark.carioscio/                        | 1          |
| 898        | local::/tmp/uploads/mrow4a@gmail.com/                      | 1          |
| 903        | local::/tmp/uploads/Helson D/                              | 1          |
| 912        | local::/tmp/uploads/mosez/                                 | 1          |
| 920        | local::/tmp/uploads/Minoru Oda/                            | 1          |
| 922        | local::/tmp/uploads/minoruod/                              | 1          |
| 924        | local::/tmp/uploads/F Helson D./                           | 1          |
| 927        | webdav::sahero@damken.cloud/remote.php/dav/files/sahero/// | 2764       |
| 928        | webdav::sahero@damken.cloud/remote.php/dav/files/sahero//  | 226277     |
| 932        | local::/tmp/uploads/reannagilcrease9188@gmail.com/         | 1          |
| 934        | local::/tmp/uploads/Alias/                                 | 1          |
| 936        | local::/tmp/uploads/Alias Name/                            | 1          |
| 938        | local::/tmp/uploads/hochzeitpatrickundmarlene/             | 1          |
| 946        | local::/tmp/uploads/Horn62/                                | 1          |
| 948        | local::/tmp/uploads/Lonilein/                              | 1          |
| 950        | local::/tmp/uploads/HenriHorn/                             | 1          |
| 952        | local::/tmp/uploads/izio/                                  | 1          |
| 957        | local::/tmp/uploads/epalma@owncloud.com/                   | 1          |
| 963        | local::/tmp/uploads/SoniaLebron2107/                       | 1          |
| 965        | local::/tmp/uploads/Gaeth/                                 | 1          |
| 967        | local::/tmp/uploads/Gaethalhijjaj/                         | 1          |
| 969        | local::/tmp/uploads/RN62645/                               | 1          |
| 971        | local::/tmp/uploads/eneubauer@owncloud.com/                | 1          |
| 974        | local::/tmp/uploads/corint900@gmail.com/                   | 1          |
| 976        | local::/tmp/uploads/pwengerter/                            | 1          |
| 978        | local::/tmp/uploads/Benedikt.Petr/                         | 1          |
| 980        | local::/tmp/uploads/grmpf/                                 | 1          |
| 983        | local::/tmp/uploads/erik.neubauer@gmail.com/               | 1          |
| 995        | home::mhuehne                                              | 2          |
| 1000       | local::/tmp/uploads/rerun_backup/                          | 1          |
| 1037       | smb::carlos@10.1.10.114//carlos//                          | 107031     |
+------------+------------------------------------------------------------+------------+

[cdamken]

Took about 15 minutes to clean all of them, great!

[cdamken]

| 3 | local::/mnt/owncloud/data/ | 55991 |

@IljaN This is what you asked today. this is a good question: why should so many entries in the main storage be deleted?

@jvillafanez any clue?

[jvillafanez]

I think any file accessed through the ownCloud's View object ends up in the filecache. With such amount of files scanned, it could be due to encryption. I've seen new View() calls there and it's very likely that we need to access to file keys at some point. If you have encryption enabled, that could explain why that storage has a big number of files.

You can remove that storage, but it will eventually grow to the same number.

We'll have to replace the View with another thing so the files don't end up in the filecache. The additional problem is that there is no unique place the View can be used. Encryption is one place I'm aware of, but there could be more.

[cdamken]

If I run: SELECT * FROM oc_storages WHERE numeric_id NOT IN (SELECT DISTINCT storage FROM oc_filecache);

I can see storages that are still there but empty:

+-----------------------------------+------------+-----------+--------------+
| id                                | numeric_id | available | last_checked |
+-----------------------------------+------------+-----------+--------------+
| wnd::carlos@10.1.10.103/carlos//  |        598 |         1 |   1600439782 |
| local::/tmp/uploads/mhuehne/      |        954 |         1 |         NULL |
| local::/tmp/uploads/Test_account/ |       1002 |         1 |         NULL |
| home::lhuelder                    |       1060 |         1 |         NULL |
| local::/mnt/owncloud/data/        |       1061 |         1 |         NULL |
+-----------------------------------+------------+-----------+--------------+

weird this one:

| local::/mnt/owncloud/data/        |       1061 |         1 |         NULL |

[cdamken]

@mmattel we should also tell in the documentation, after running the command we have to run:

OPTIMIZE TABLE oc_ficache;

or better:

mysqlcheck -o owncloud

@jvillafanez @pako81 @phil-davis what do you think?

[phil-davis]

what do you think?

Is the table usually big enough that "optimize" makes much performance difference

[mmattel]

For any command that should run, I am not in favour of database sql commands or mysql versions of it. This should be managed by the occ command internally. Maybe to extend that one.

[mmattel]

Addon, what to do when NOT running mysql/mariadb ? --> extend the internal command for the functionality.

I ran mysqlcheck -o owncloud on my instance --> I got on all tables:

note     : Table does not support optimize, doing recreate + analyze instead
status   : OK

I am very reluctant to show these details to customers...

[jvillafanez]

If anything, I'd say something generic like "if you've deleted a huge amount of rows, check your DB to optimize / compact the table to improve performance".
The problem I see is that we don't know if it's really needed in all the DBs (maybe they keep the records clean, or it's optimized asynchronously), or when it's needed (after 1k rows? 500k rows?)

I assume that if they delete millions of rows and then the DB doesn't improve the performance automatically, they should check the DB manual to know what they can do or what is the problem

[IljaN]

We should stay generic as @jvillafanez described and not recommend specific commands. In MariaDB for example the index size stays the same after a lot of deletions but the empty space is reserved for subsequent inserts.

Also from mysql docs:

[pako81]

I think in the case shares are created for files located on those mountpoints, upon removing the mount point configuration from the web UI, the candidates are not properly found by the command as entries in oc_mounts pointing to that specific storage_id will exist for the shares' receivers.

So the condition WHERE m.mount_point IS NULL (https://github.com/owncloud/core/blob/master/apps/files/lib/Command/RemoveStorageCache.php#L181) is not verified. @jvillafanez FYI