This is needed because in some cases like LDAP, the user manager itself
might trigger avatar updates which would internally also call
initMountPoints with the same user. This could cause the same user to
be setup twice, and in some sharing situations could cause recursive
deduplication of shares by adding "(2)" every time.
This makes sure that even if a NFD file name exists, it is found by the
storage and will be visible to higher layers. Even though the file will
be discarded anyway there, it gives the scanner a chance to display a
warning at least.
initMountPoints is marking a user as successfully initialized too
early. If the user was not found an NoUserException was thrown, the
second time initMountPoints is called would not rethrow the exception
and happily continue.
This fix makes sure that we consistently throw NoUserException when
initMountPoints is called repeatedly with invalid users.
In some scenarios initMountPoints is called with an empty user, and
also there is no user in the session.
In such cases, it is unsafe to let the code move on with an empty user.
Fixes#22467
This can go wrong when an app (take the ldap app) DIs something that
needs the rootFolder. This break if we use cookie auth since then we
know the user at that point and thus try to setup the fs for that user.
However if there are then incomming shares from an ldap user they will
fails since the user manager can't find them yet.
Now getRootFolder does not setup the fs for any user.
Currently the `getPath` methods returned `NULL` in case when a file with the specified ID does not exist. This however mandates that developers are checking for the `NULL` case and if they do not the door for bugs with all kind of impact is widely opened.
This is especially harmful if used in context with Views where the final result is limited based on the result of `getPath`, if `getPath` returns `NULL` PHP type juggles this to an empty string resulting in all possible kind of bugs.
While one could argue that this is a misusage of the API the fact is that it is very often misused and an exception will trigger an immediate stop of execution as well as log this behaviour and show a pretty error page.
I also adjusted some usages where I believe that we need to catch these errors, in most cases this is though simply an error that should hard-fail.
Some code paths called the `normalizePath` functionality with types other than a string which resulted in unexpected behaviour.
Thus the function is now manually casting the type to a string and I corrected the usage in list.php as well.
It's better to encode the string to prevent possible (yet unknown) bugs in combination with PHP's type juggling.
Previously the boolean statements evaluated to either an empty string (false) or a not empty one (true, then it was 1). Not it always evaluates to false or true.
This also removes a stray - that was not intended there but shouldn't have produced any bugs. Just to increase readability.
Thanks @nickvergessen for spotting.
Addresses https://github.com/owncloud/core/pull/13235/files#r22852319
`normalizePath` is a rather expensive operation and called multiple times for a single path for every file related operation.
In my development installation with about 9GB of data and 60k files this leads to a performance boost of 24% - in seconds that are 1.86s (!) - for simple searches. With more files the impact will be even more noticeable. Obviously this affects every operation that has in any regard something to do with using OC\Files\Filesystem.
Part of https://github.com/owncloud/core/issues/13221
Robin Appelman
Vincent Petry
Morris Jobke
Joas Schilling
Lukas Reschke
Robin Appelman
Christoph Wurst
Joas Schilling
Roeland Jago Douma
Thomas Müller
Scrutinizer Auto-Fixer
Jörn Friedrich Dreyer
Jenkins for ownCloud