/backport to stable28

Fast review ~!

@mejo- is the better person when it comes to backend changes.

I have some uninformed questions though...

• What will happen if collectives is not installed and the used class is not available?
  Will php be happy with that?
• You are talking about a shared collective - are you referring to a collective that has been explicitly shared by link or a normal collective with multiple members?

In general it seems not ideal to me to have collectives specific code in server. I wonder if we could instead make CollectiveStorage a SharedStorage as that could happen on the collectives side of things.

I remember that collectives storage was designed closely to what groupfolders does. Does this issue not occur with groupfolders ? How is the groupfolders implementation different from collectives?

@mejo- is the better person when it comes to backend changes.

I have some uninformed questions though...

• What will happen if collectives is not installed and the used class is not available?
  Will php be happy with that?

I tested this case and had no problem without Collectives installed, since instanceOfStorage() will only check the class name and it should not matter, if the class actually exists.

But I agree it would be better not to rely on multiple classes here but instead have a common method which can be used. Maybe adding a method isShared() to the Storage interface may help. This sould return true by SharedStorage or CollectiveStorage and otherwise false so the scanner knows when to ignore the storage:

			// don't scan shared storages, these can be scanned when scanning the owner's storage
			if ($storage->isShared()) {
				continue;
			}

However this would involve substantial refactoring of the backend code.

• You are talking about a shared collective - are you referring to a collective that has been explicitly shared by link or a normal collective with multiple members?

I refer to a normal collective which is shared with multiple members of a circle.

@max-nextcloud @mejo- any update?

@arnowelzel psalm said no

Since using the class name of the Collective storage is not possible in any way without triggering a psalm error (even when the class exists it is not allowed as parameter for \OC\Files\Storage\Wrapper\Wrapper::instanceOfStorage()) I changed the test as following:

			// don't scan received local shares or collectives, these can be scanned when scanning the owner's storage
			if (substr($storage->getId(), 0, 6) !== 'home::') {
				continue;
			}

The idea here is, that only home storages should get scanned. Recieved shared storage start with shared:: and Collectives, which trigger the error, report IDs as local:: followed by the physical path. However I don't know if any other storages which should indeed be scanned, also report an ID starting with something different from home::.

I also noticed the following code in \OCA\Collectives\Mount\CollectiveStorage - maybe in the past this problem was mitigated by using NoopScanner which does not exist any longer?

	public function getScanner($path = '', $storage = null): Scanner {
		if (!$storage) {
			$storage = $this;
		}
		if ($storage->instanceOfStorage(ObjectStoreStorage::class)) {
			// NoopScanner is private API and kept here for compatibility with older releases
			$storage->scanner = class_exists(NoopScanner::class) ? new NoopScanner($storage) : new ObjectStoreScanner($storage);
		} elseif (!isset($storage->scanner)) {
			$storage->scanner = new Scanner($storage);
		}
		return $storage->scanner;
	}

Probably @icewind1991 is the best to decide whether it's a good idea to limit scanning to home storages.

What is stopping the collectives from being scanned correctly in the first place?

What is stopping the collectives from being scanned correctly in the first place?

They are shared storages like SharedStorage and thus don't provide a physical path which can be scanned.

If they can't be scanned at all then having them use NoopScanner is probably the best (shared storage should also move to that really)

If they can't be scanned at all then having them use NoopScanner is probably the best (shared storage should also move to that really)

Well - NoopScanner does not exist any longer.

Right, it got moved to ObjectStoreScanner when it got slightly less noop, should be good to still use that one or just create your own

Right, it got moved to ObjectStoreScanner when it got slightly less noop, should be good to still use that one or just create your own

It seems, this is what Collectives is using right now - but it does not work. See https://github.com/nextcloud/collectives/blob/main/lib/Mount/CollectiveStorage.php#L62-L74:

public function getScanner($path = '', $storage = null): Scanner {
		if (!$storage) {
			$storage = $this;
		}
		if ($storage->instanceOfStorage(ObjectStoreStorage::class)) {
			// NoopScanner is private API and kept here for compatibility with older releases
			$storage->scanner = class_exists(NoopScanner::class) ? new NoopScanner($storage) : new ObjectStoreScanner($storage);
		} elseif (!isset($storage->scanner)) {
			$storage->scanner = new Scanner($storage);
		}
		return $storage->scanner;
	}

Since no one has an idea about this I suggest to close this. The code is way outdated anyway.