mb_detect_encoding is in the fallback we ship in the polyfill library, mb_strcut is not. Thus this lead to a false positive and ownCloud would just break.
the login password changed at the user back-end (e.g ldap). Such failures will
be handled after login correctly by allowing the user to adjust the passwords
Whenever part chunks are written, every fwrite in the write loop will
reset the mtime to the current mtime. Only at the end will the touch()
operation set the mtime to now + ttl, in the future.
However the GC code is expecting that every chunk with mtime < now are
old and must be deleted. This causes the GC to sometimes delete part
chunks in which the write loop is slow.
To fix this, a tolerance value is added in the GC code to allow for
more time before a part chunk gets deleted.
E-tag propagation replies on the mtime of the file. Order of events:
1. add file 'foo.txt' with content 'bar'
2. Set mtime to now() - 1
3. Check if etag changed.
Now this goes right often when 1 and 2 happen in the same second.
However imagine
1. add file 'foo.txt' with content 'bar' (at t=0.999)
2. Set mtime to now() - 1 (at t=1.001)
Now the mtime will be set to the same time. Thus not chaning the etag.
Currently testing the updates is a big problem and not really super easy possible. Since we now have a new updater server we should also make this configurable so that people can properly test updates.
The current logic for mod_rewrite relies on the fact that people have properly configured ownCloud, basically it reads from the `overwrite.cli.ur
l` entry and then derives the `RewriteBase` from it.
This usually works. However, since the ownCloud packages seem to install themselves at `/owncloud` (because subfolders are cool or so…) _a lot_ of people have just created a new Virtual Host for it or have simply symlinked the path etc.
This means that `overwrite.cli.url` is wrong, which fails hard if it is used as RewriteBase since Apache does not know where it should serve files from. In the end the ownCloud instance will not be accessible anymore and users will be frustrated. Also some shared hosters like 1&1 (because using shared hosters is so awesome… ;-)) have somewhat dubious Apache configurations or use versions of mod_rewrite from the mediveal age. (because updating is money or so…)
Anyhow. This makes this explicitly an opt-in configuration flag. If `htaccess.RewriteBase` is set then it will configure index.php-less URLs, if
admins set that after installation and don't want to wait until the next ownCloud version they can run `occ maintenance:update:htaccess`.
For ownCloud 9.0 we also have to add a repair step to make sure that instances that already have a RewriteBase configured continue to use it by copying it into the config file. That way all existing URLs stay valid. That one is not in this PR since this is unneccessary in master.
Effectively this reduces another risk of breakage when updating from ownCloud 8 to ownCloud 9.
Fixes https://github.com/owncloud/core/issues/24525, https://github.com/owncloud/core/issues/24426 and probably some more.
When moving files via WebDAV I sometimes got
PHP Fatal error: Nesting level too deep - recursive dependency? in /var/www/owncloud/lib/private/files/view.php on line 729
This small change has fixed the problem for me
Robin Appelman
Joas Schilling
Vincent Petry
Lukas Reschke
Fabian
Björn Schießle
Piotr Filiciak
Carla Schroder
Joas Schilling
Robin Appelman
Lukas Reschke
VicDeo
Thomas Müller
Thomas Müller
Roeland Jago Douma
Pau
Petr Svoboda