[stable9.1] Store avatars outside of the home

[PVince81]

Inside a hidden ".avatars" folder.
Doesn't require home FS setup

For #22414

@DeepDiver1975 @butonic

[mention-bot]

@PVince81, thanks for your PR! By analyzing the annotation information on this pull request, we identified @rullzer, @icewind1991 and @blizzz to be potential reviewers

[PVince81]

• repair steps
• unit tests

[PVince81]

• forward port to master

[butonic]

please dont use a hidden folder. The admin will just wonder where his space went ...

we have a configurable location for tmp and for cached files: https://github.com/owncloud/core/blob/master/config/config.sample.php#L972

we should be able to prevent the filesystem setup in the sync job by checking if the user ever logged in.

shouldnt the user backend provide the avatar?

[butonic]

also see #25802

[PVince81]

Until we have #18029 we'd need to find a pretty unique name.
Or maybe we could have a folder "metadata/avatars" for global metadata instead.

[PVince81]

• change folder name to be non-conflicting and non-hidden

[PVince81]

shouldnt the user backend provide the avatar?

It could make sense to change OC to work that way.
The current way, from my understanding, is that the avatar manager is not directly tied to the user manager. The avatar manager always relies on the avatar being present on the FS. The writing to FS happens when setting the avatar on the avatar manager.
In the case of local users, the setting is done by the personal page code.
In the case of LDAP, the LDAP code will set the avatar into the manager, which creates a local FS copy.

If we'd move this to be dependent on the user backend instead it means that the local user backend would always rely on the FS to get the avatar, but the LDAP backend would need to retrieve the avatar every time from LDAP or implement its own caching mechanism.

[PVince81]

we should be able to prevent the filesystem setup in the sync job by checking if the user ever logged in.

This is not always enough. The FS setup here doesn't only setup the user's home folder but also every other shared storage and external storage, which can be slower. (it was slower when there was the shared storage recursion bug). Best is to require no user-specific FS setup at all, like in this PR.

[DeepDiver1975]

shouldnt the user backend provide the avatar?

Just like the overall plan to store any user account specific information in a central place ( 😉 user account table 😉 ) - avatars have to be stored the same way: central in one place.

Why?
Just like anything else in ownCloud we need to optimze anything we do to be fast on read.

[DeepDiver1975]

This is not always enough. The FS setup here doesn't only setup the user's home folder but also every other shared storage and external storage, which can be slower. (it was slower when there was the shared storage recursion bug). Best is to require no user-specific FS setup at all, like in this PR.

I'd love to discuss about a design where no file system setup magic is required and all data can 'easily' be queried from the db .... to optimize on read.

e.g. a propfind to list folders and files should be easily executed on a single db query.

.... anyway I'm loosing focus ...

[PVince81]

I've added a repair step, check it out!

Also I renamed the folder to "metadata-avatars", but we should discuss a better folder structure for outside the user's home.
Some suggestions:

• "metadata/$userid/avatars"
• "metadata/avatars/$userid"
• "metadata-avatars/$userid" (current one)

[PVince81]

grrr, encryption wrapper getting in the way, will fix

[PVince81]

Another fix that makes it work with LDAP and cases where the user exists but the home folder doesn't.

[PVince81]

Unlikely to make it into 9.1 as it's a big change.

Resent to master / 9.2 here: #26124

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