They are an empty array by default. If you don't initialize then
accessing them via the setter will throw a type error.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Technically, saying that a storage has no updates when it's not
available is correct.
This makes it possible to retrieve the cache entry for the mount point
and also to list and remove unavailable federated shares.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
- Provide metadata
- Dynamic displayId
- Add appId
- Filter out unused parameter config properties from the existing profile config
Signed-off-by: Christopher Ng <chrng8@gmail.com>
The Calendar app needs to access calendars of a given principal in the
back-end. The new calendar providers were not accessible for apps before
this patch. Now they can access the ICalendar objects on demand.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Make sure that when a user copy a file from a directory they don't have
all permissions to a directory where they have more permissions, the
permissions are correctly set to the one from the parent taget folder.
This was caused by the ObjectStoreStorage::copyFromStorage using
the jailed storage and cache entry instead of the unjailed one like other
storages (the local one).
Steps to reproduce
+ Use object storage
+ Create a groupfolder with one group having full permission and another one
who can just read files.
+ With an user who is in the second group, copy a file from the groupfolder to
the home folder of this user.
+ The file in the home folder of the user will be read only and can't be deleted
even though it is in their home folder and they are the owner. In oc_filecache,
the permissions stored for this file are 1 (READ)
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
When using and object store as primary storage and using the default
encryption module at the same time, any encrypted file would be truncated
when read, and a text error message added to the end.
This was caused by a combination of the reliance of the read functions on
on knowing the unencrypted file size, and a bug in the function which
calculated the unencrypted file size for a given file.
In order to calculate the unencrypted file size, the function would first
skip the header block, then use fseek to skip to the last encrypted block
in the file. Because there was a corresponence between the encrypted and
unencrypted blocks, this would also be the last encrypted block. It would
then read the final block and decrypt it to get the unencrypted length of
the last block. With that, the number of blocks, and the unencrypted block
size, it could calculate the unencrypted file size.
The trouble was that when using an object store, an fread call doesn't
always get you the number of bytes you asked for, even if they are
available. To resolve this I adapted the stream_read_block function from
lib/private/Files/Streams/Encryption.php to work here. This function
wraps the fread call in a loop and repeats until it has the entire set of
bytes that were requested, or there are no more to get.
This fixes the imediate bug, and should (with luck) allow people to get
their encrypted files out of Nextcloud now. (The problem was purely on
the decryption side). In the future it would be nice to do some
refactoring here.
I have tested this with image files ranging from 1kb to 10mb using
Nextcloud version 22.1.0 (the nextcloud:22.1-apache docker image), with
sqlite and a Linode object store as the primary storage.
Signed-off-by: Alan Meeson <alan@carefullycalculated.co.uk>
We want to keep offering our push notification service for free, but large
users overload our infrastructure. For this reason we have to rate-limit the
use of push notifications. If you need this feature, consider setting up your
own push server or using Nextcloud Enterprise.
Signed-off-by: Joas Schilling <coding@schilljs.com>
- both $userData and $defaultUserData have numeric indices
- each element contains at least the name and other fields
- appending the missing data array is sufficient
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
