It seems Phpunit < 9 was case insensitive.
Fixed the phpunit config to target the correct name for the "Core" test
directory.
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
The command is meant to be used when the fonts used to render texts
("core/fonts/NotoSans-Regular.ttf" and "core/fonts/NotoSans-Bold.ttf")
are changed (for example, to add support for other scripts). The avatar
and text file previews will be removed, so they will be generated again
with the updated font when needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Generated avatars as well as text file previews are rendered using the
"core/fonts/NotoSans-Regular.ttf" font. The file was the standard hinted
"NotoSans-Regular.ttf" file from https://www.google.com/get/noto/.
However that file does not cover some non LGC (Latin, Greek, Cyrillic)
scripts, like Arabic, Devanagari or Hebrew, to name a few.
Markdown file previews also use "core/fonts/NotoSans-Bold.ttf", which is
in the same situation as the regular one.
Due to limitations in the TTF format it is not possible to provide a
single file for each style that includes all Noto fonts. However, it is
possible to add more scripts to the standard "NotoSans-Regular.ttf" and
"NotoSans-Bold.ttf" files (although no CJK (Chinese, Japanese, Korean)
glyph can be included due to the aforementioned limitations).
This commit replaces the standard files with an extended version created
using the Noto Tools. The build script (as well as a patch for the Noto
Tools) is also included for reference and to be able to update the font
files in the future if needed.
Due to the additional scripts added the font files are now much larger,
although this does not seem to increase the time spent rendering LGC
scripts.
Note that the file for the bold style still contains less scripts than
the regular one, as not all scripts supported by Noto have a bold
weight.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
some smb servers are very insistent in reporting that the root of the share is readonly, even if it isn't.
This works around the problem by adding a hidden option to overwrite the permissions of the root of the share.
This can be enabled using
```bash
occ files_external:config <mount id> root_force_writable true
```
where you can find your mount id using
```bash
occ files_external:list
```
Signed-off-by: Robin Appelman <robin@icewind.nl>
Updating a user or group share now uses the correct method for the
validation of the expiration date. Instead of using the one from links
it uses the one for internal shares.
To avoid future confusion, the method "validateExpirationDate" has been
renamed to "validateExpirationDateLink".
Signed-off-by: Vincent Petry <vincent@nextcloud.com>
The remote URL of a share is always stored in the database with a
trailing slash. However, when a cloud ID is generated trailing slashes
are removed.
The ID of a remote storage is generated from the cloud ID, but the
"cleanup-remote-storage" command directly used the remote URL stored in
the database. Due to this, even if the remote storage was valid, its ID
did not match the ID of the remote share generated by the command and
ended being removed.
Now the command generates the ID of remote shares using the cloud ID
instead, just like done by the remote storage, so there is no longer a
mismatch.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
even thought we currently have no proper way of limiting the search itself, we can at least limit the construction of the result objects.
this saves about 40% of the time spend in the search request in my local testing
Signed-off-by: Robin Appelman <robin@icewind.nl>
streams get closed automatically when dropped, and in some cases the stream seems to be already closed by the S3 library, in which case trying to close it again will raise an error
Signed-off-by: Robin Appelman <robin@icewind.nl>
Vincent Petry
John Molakvoæ (skjnldsv)
Nextcloud bot
Robin Appelman
Daniel Calviño Sánchez
John Molakvoæ
Valdnet
Roeland Jago Douma
Morris Jobke
Julius Härtl
Roeland Jago Douma