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>
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>
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>
Apparently the if statement doesn't work in all cases (even if I could
not reproduce it). So for the time being we will just not directly
stream to swift.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If for whatever reason appdata got into a strange state this will at
least propegate up and not make it do boom the next run.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
we can only store etags up to 40 characters long in the database, so when we get an etag that's longer we simply hash it to bring down the length
Signed-off-by: Robin Appelman <robin@icewind.nl>
Alert in debug mode only when trying to mount non compatible DNS bucket name (in order to not flood the logs)
Signed-off-by: Sébastien Cat <sebastien.cat@inra.fr>
The new created bucket should respect the DNS compatibility, nevertheless, Nextcloud should accept to mount "old created" buckets that does not respect DNS compatibility (Backward compatibility, or compatibility with CEPH).
Signed-off-by: Sébastien Cat <sebastien.cat@inra.fr>
