* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If you try to do something on a DAV mount (external or federated share)
that is not allowed. We should not mark the storage as not available but
just fail somewhat gracefully.
Now by catching this and just properly returning the operation will just
fail (and notify the user) which is already a lot better then marking
the storage as unavailable and doing boom.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#15048
Catches the case where a full mimetype is sumbitted in the where like
clause. Before we didn't catch this and it was just forwarded as is
causing invalid queries.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
the target storage doesn't need additional handling for wrappers as the wrappers implementation of moveFromStorage already deals with that
Any storage based on local storage isn't affected by this as local storage already has it's own way of handling with this
Signed-off-by: Robin Appelman <robin@icewind.nl>
In case the path we are currently in is inside the appdata_* folder,
the original getById method does not work, because it can only look inside
the user's mount points. But the user has no mount point for the root storage.
So in that case we directly check the mount of the root if it contains
the id. If it does we check if the path is inside the path we are working
in.
Signed-off-by: Joas Schilling <coding@schilljs.com>
We already catch the result value. Having the warning being logged
explicitly doesn't help and polutes the log.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This can happen for valid reasons (multiple users writing at the same
time) with for example the text app. Apps should properly handle it. No
reason to log it by default.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If userA has a lot of recent files. But only shares 1 file with userB
(that has no files at all). We could keep searching until we run out of
recent files for userA.
Now assume the inactive userB has 20 incomming shares like that from
different users. getRecent then basically keeps consuming huge amounts
of resources and with each iteration the load on the DB increases
(because of the offset).
This makes sure we do not get more than 3 times the limit we search for
or more than 5 queries.
This means we might miss some recent entries but we should fix that
separatly. This is just to make sure the load on the DB stays sane.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Some of the READs otherwise use HTTP/1.0 which is not always supported
by all backends. HTTP/1.1 is there since 1999 way longer than S3 so safe
to assume it is always there IMO.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
