To avoid extra truncate on non WORM file systems, add a new config
option `localstorage.unlink_on_truncate`, which defaults to false.
The OC\Files\Storage\Local is update to respect that option.
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
always apply the wrapper but have the wrapper get the quota lazily only when an operation where quota is applied is performed
Signed-off-by: Robin Appelman <robin@icewind.nl>
Some filesystems run as a Write-Once-Read-Many storages. This
makes them impossible to use with NexeCloud, as the file system
layers uses `truncate` syscall (through file_put_contents function).
As Nextcloud is never updates existing files, removing the old entry
and creatint a new one on update will allow NextCoud to update on such
file systems.
Update Local#fopen and Local#file_put_contents to remote existing
file before truncating.
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
This is an helpful helper that should be used in more place than just
server and this is already the case with groupfodlers, deck, user_oidc
and more using it, so let's make it public
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
Commit 451c06d introduced override for umask value.
This is needed to avoid broken env configuration or dirty workers
to mess with the permissions when creating new files.
Most Nextcloud, that does not integrate with external software
would work fine with an hard-coded value (451c06d set it at 022).
Advanced install may require more flexibility, as such this commit
exposes the "umask override value" as configuration parameter:
`localstorage.umask`
It defaults to 0022 both in code and in config/config.sample.php .
Signed-off-by: Martin Brugnara <martin@0x6d62.eu>
When moving a file to trash with encryption enabled, the cache gets
moved before the actual file. According to @icewind1991 this is in order
to not break object storage.
When moving a file from an unencrypted storage (e.g. a collectives
storage) to the encrypted trashbin storage, this causes errors, see
This commit fixes it by doing `updateEncryptedVersion()` on the target
cache entry *if* the source cache entry doesn't exist anymore, but the
corresponding target cache entry does exist already.
Fixes: #26544
Signed-off-by: Jonas Meurer <jonas@freesources.org>
Fixes an issue with transfer ownership in move mode where the folder
"files_encryption/keys/files" already exists.
Instead of failing, its existence is checked before calling mkdir.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
In case of error there is no guarantee that $source or $target is set or
is a resource when handling an error.
Without this fix, there's a risk that fclose will fail and the actual
exception will not be thrown, making it impossible to find out about the
root cause.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
Directory entry file names are now normalized in getMetaData(),
getDirectoryContents() and opendir().
This makes the scanner work properly as it assumes pre-normalized names.
In case the names were not normalized, the scanner will now skip the
entries and display a warning when applicable.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
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>
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>
Using advanced ACL, it is possible that an user has access to a
directory but not to a subdirectory, so the copying use
Common::copyFromStorage instead of Local::copyFromStorage.
Fix https://github.com/nextcloud/groupfolders/issues/1692
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
The current phpdoc of IStorage#file_put_contents doesnt corresponds to
it's actual usage in code, e.g.
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
The OC\Files\Storage\Local#writeStream use system provided file_put_contents.
However, it overrides file_put_contents, thus expects that the default behaviour
can be different.
Use Local#file_put_contents in writeStream to benefit from class specific functionality.
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
* removes the ability for users to import their own certificates (for external storage)
* reliably returns the same certificate bundles system wide (and not depending on the user context and available sessions)
The user specific certificates were broken in some cases anyways, as they are only loaded if the specific user is logged in and thus causing unexpected behavior for background jobs and other non-user triggered code paths.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Côme Chilliet
Richard Steinmetz
Robin Appelman
szaimen
Carl Schwan
Vincent Petry
Tigran Mkrtchyan
Git'Fellow
blizzz
Martin Brugnara
Louis
Max Kunzelmann
Jonas Meurer
Joas Schilling
acsfer
alanmeeson
John Molakvoæ
Daniel Kesselberg
Julius Härtl
Lukas Reschke
Rid
John Molakvoæ (skjnldsv)
Roeland Jago Douma
Roeland Jago Douma
dependabot-preview[bot]
Jasper Knockaert
Johannes Leuker
Morris Jobke
Christoph Wurst
aler9