make easier the occ files:scan --repair

[cdamken]

Related to #31165

The storages do not represent which users are the one to have to be repaired.

it will be much easier for the administrators:

occ files:scan --repair [Storage Number]

because not all the storage from one user have to be repaired.

or at least in the output from #31165 could say which users are the one who has to be repaired?

some admins do not know where to search which is the owner of each storage.

@tomneedham @butonic @PVince81

[ownclouders]

GitMate.io thinks the contributor most likely able to help you is @PVince81.

Possibly related issues are #31077 (occ files:scan error), #19115 (occ files:scan's memory consumption grows with amount of files scanned), #26516 (occ file scan on some big file failed), #4206 (filecache scans files forever), and #23451 (occ files:scan aborted when lacking permissions).

[mmattel]

What about splitting:
occ files:scan --repair --check
which gives you the storage number(s) needing a repair, then
occ files:scan --repair [Storage Number, Storage Number, ...]

[mmattel]

I vote for this. During upgrading to 10.0.8 I got the following message:

• Repair warning: The file cache contains entries where the parent id does not point to any existing entry for the following storage numeric ids: 11
• Repair warning: Please run occ files:scan --all --repair to repair all affected storages

Running the repair command for all users (as you do not know which one is affected) can take a very long time especially on many users and if there are storage types with a very slow connection...
(The command on my system is now running for hours beeing in singleuser --on = no user access possible)

[PVince81]

I suggest adding an option --storage-numeric-id for that and apply it to anything related to scanning, repair or not. (we already have --path)

[PVince81]

Note that long term we except that such repairing is not necessary any more. There were some older OC versions that caused file cache corruption when moving folders cross-storage and the issue is fixed, so we expect that such corruption will never occur again. So once everyone have fixed their storages the command should not be needed any more.

[mmattel]

But dont we need then also an option to tell which storage id to be checked?

[PVince81]

yes, the option will be useful anyway

[stale]

This issue has been automatically closed.