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>
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>
This is bit hacky but a start to lock the SCSS compiler properly
Retry during 10s then give up
Properly get error message
Do not clear locks and properly debug scss caching
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>
getDirectoryListing can throw a NotFoundException or a RuntimeException.
The repair step should be skipped if the cache directory is missing so
a catch for both exceptions is required.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
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>
not all storage backends can handle setting the mtime and they might
not always handle that error correctly.
Signed-off-by: Robin Appelman <robin@icewind.nl>
Without this patch the hook does not transport the information whether the login is
done with an app password or not. The suspicious login app requires the parameter
to function correctly, hence adding it will make suspicious login detection also possible
with SAML users.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
The header is the full http header like: HTTP/1.1 304 Not Modified
So comparing this to an int always yields false
This also makes the 304 RFC compliant as the resulting content length
should otherwise be the length of the message and not 0.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Robin Appelman
Christoph Wurst
Daniel Kesselberg
Arthur Schiwon
Roeland Jago Douma
Joas Schilling
Georg Ehrke
Roeland Jago Douma
Julius Härtl
Marcel Klehr
Morris Jobke
Maxence Lange
John Molakvoæ (skjnldsv)