while some code paths do wrap the "raw" locking exception into one with a proper path, not all of them do
by adding the proper path to the original exception we ensure that we always have the usefull information in out logs
Signed-off-by: Robin Appelman <robin@icewind.nl>
The S3 client enables this by default and then tries to read
`.aws/config`. This causes `open_basedir` restriction related error for
some setups. So this patch disables the CSM because it's most likely
unused anyway.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
while this scan *should* never be triggered, it's good to have some failsafe to ensure
that the users home contents don't end up getting scanned in the root storage
Signed-off-by: Robin Appelman <robin@icewind.nl>
Some S3 providers need a custom upload part size (500 MB static value in Nextcloud).
Here is a commit to change this value via S3 configuration, instead of using S3_UPLOAD_PART_SIZE constant.
A new parameter is added for an S3 connection : uploadPartSize
Signed-off-by: Florent <florent@coppint.com>
Right now if you want to get events via the Node API you have to have a
real instance of the Root. Which in turns sets up the whole FS.
We should make sure this is done lazy. Else enabling the preview
generator for example makes you setup the whole FS on each and every
authenticated call.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Else if a lot of writes happen. It might happen that an old stat result
is used. Resulting in a wrong file size for the file. For example the
text app when a lot of people edit at the same time.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Until now, you wouldn't be able to create
objects larger that 5GB.
It's somewhat related with pull #18883
Signed-off-by: Adrian Brzezinski <adrian.brzezinski@eo.pl>
Improves efficiency when downloading files from Swift storage.
Before, files were downloaded and then pushed back to user.
That behaevior causes all kinds of performance problems.
Now, files are streamed directly to user.
Signed-off-by: Adrian Brzezinski <adrian.brzezinski@eo.pl>
Currently you need to use `opendir` and then call `getMetadata` for
every file, which adds overhead because most storage backends already
get the metadata when doing the `opendir`.
While storagebackends can (and do) use caching to relief this problem,
this adds cache invalidation dificulties and only a limited number of
items are generally cached (to prevent memory usage exploding when
scanning large storages)
With this new methods storage backends can use the child metadata they
got from listing the folder to return metadata without having to keep
seperate caches.
Signed-off-by: Robin Appelman <robin@icewind.nl>
hashes are set in "X-Hash-MD5", "X-Hash-SHA1" and "X-Hash-SHA256" headers.
these headers are set for file uploads and the MOVE request at the end of a multipart upload.
Signed-off-by: Robin Appelman <robin@icewind.nl>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
instead of first creating an empty file and then writing the content.
This solves the overhead of creating an empty file with the common pattern:
```php
$file = $simpleFilder->newFile('foo.txt');
$file->putContent('bar.txt');
```
roughly halving the number of storage and database operations that need to be done when creating a `SimpleFile`.
This is not automatically done with `File` because that has a more complex api which I'm more hesitant to touch.
Instead the `Folder::newFile` api has been extended to accept the content for the new file.
In my local testing, the overhead of first creating an empty file took about 20% of the time for preview generation
Signed-off-by: Robin Appelman <robin@icewind.nl>
This is done by adding a
```xml
<d:eq>
<d:prop>
<oc:owner-id/>
</d:prop>
<d:literal>$userId</d:literal>
</d:eq>
```
clause to the search query.
Searching by `owner-id` can only be done with the current user id
and the comparison can not be inside a `<d:not>` or `<d:or>` statement
Signed-off-by: Robin Appelman <robin@icewind.nl>
normally this shouldn't be a problem, but cache/storage desync might cause this
so this adds some failsafe to ensure we dont corrupt the cache further
the minimum value is set to -1 instead of 0 in order to triger a background scan
on the folder and figure out the size properly
Signed-off-by: Robin Appelman <robin@icewind.nl>
* 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>
Christoph Wurst
Roeland Jago Douma
Robin Appelman
Daniel Kesselberg
Florent
Roeland Jago Douma
Adrian Brzezinski
Scott Dutton
Morris Jobke
Christoph Wurst
Julien Lutran
Joas Schilling
Julius Härtl
Lukas Stabe
tobiasKaminsky
Greta Doci
Arthur Schiwon
Marcel Klehr
John Molakvoæ
martink-p