having the "cache rename" after the "storage move" caused the target
to get the fileid from the source file, without taking care that the object
is stored under the original file id.
By doing the "cache rename" first, we trigger the "update existing file"
logic while moving the file to the object store and the object gets stored for the
correct file id
Signed-off-by: Robin Appelman <robin@icewind.nl>
With 4152216bd8 these two interfaces got
deprecated with the reasoning that we only need the base PSR interface.
However, there are cases where in Nextcloud you still want to have a
specific container (the one for the app vs the one for the server) when
you either have a container injected or query one from a container.
With a single interface that would not be possible. So it's probably
better if we leave the two interfaces, but only have them extend the PSR
interface. IContainer – with the custom methods – shall still be phased
out, but the two other sub interfaces can stay for tagging purposes.
Tagging means that no methods shall be added.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
The interface method has already been deprecated, but if some code uses
the concrete type instead, the deprecation is not shown (by phpstorm),
so I think it's better to have this method tagged as well.
The "fix" for this deprecation is to simply use `get` instead of
`query`. Right now this will work 100% the same, but the goal is to slim
down the interface and only use what PSR-11 offers.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Else people might have the feeling this is also doing 2FA. And since it
is only prefered it can be ignored and hacked around.
Once we have proper 2FA with webauthn in one go this probably needs to
be revisted.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The logger service was always intended to follow the PSR-3 interface.
It's time to embrace this and switch over to the "official" API,
hence this custom interface can be slowly phased out.
With Nextcloud 20 the logger also got support for
* App id filled out automatically
* Exceptions handling (as replacement for logException)
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Just like for ILogger we should have a version that has the app ID
pre-set for the context (unless overwritten) so that each log entry can
be traced back to the app that produced it.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Service locators are an anti pattern. These getters just make it more
appealing to do the wrong thing. If you want to locate a service the bad
way, just use the `get` method on a container – it will do the same in
also one line of code.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Joas Schilling
Joas Schilling
Morris Jobke
Nextcloud bot
Robin Appelman
Julius Härtl
onehappycat
Simon Spannagel
Roeland Jago Douma
Christoph Wurst
Roeland Jago Douma