https://webdav.mediencenter.t-online.de returns invalid response code.
e.g.
{"reqId":"f9a1c394b98108e4e5ca62bf47829c64","remoteAddr":"81.189.45.224","app":"PHP","message":"Undefined offset: 2 at \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/Sabre\/DAV\/Client.php#569","level":3,"time":"2015-03-25T18:25:48+00:00","method":"GET","url":"\/index.php\/apps\/files\/ajax\/getstoragestats.php?dir=External%2FT-Cloud%2FTests"}
e.g.
{"reqId":"3407d66672b3cef206b0af883e49bff4","remoteAddr":"46.74.125.245","app":"PHP","message":"Undefined index: {DAV:}getlastmodified at \/var\/www\/owncloud\/lib\/private\/files\/storage\/dav.php#563","level":3,"time":"2015-03-25T16:33:21+00:00"}
In the past it seems the update permission was needed to be able to
rename shared mounts, but it doesn't seem to be the case any more.
Removing the "update" permission that used to be added automatically
fixes the read-only permission check when trying to overwrite a
read-only file over WebDAV.
Without this files with a ` (backtick) in the beginning of the filenames where simply not correctly referenced as the ` got removed. This can lead to all possible havoc situations.
Should get backported to stable8 and in future we might consider if it is really worth to backport such changes when it is just for SQLite 🙈
Regression of https://github.com/owncloud/core/pull/14734
- VObject fixes for Sabre\VObject 3.3
- Remove VObject property workarounds
- Added prefetching for tags in sabre tags plugin
- Moved oc_properties logic to separate PropertyStorage backend (WIP)
- Fixed Sabre connector namespaces
- Improved files plugin to handle props on-demand
- Moved allowed props from server class to files plugin
- Fixed tags caching for files that are known to have no tags
(less queries)
- Added/fixed unit tests for Sabre FilesPlugin, TagsPlugin
- Replace OC\Connector\Sabre\Request with direct call to
httpRequest->setUrl()
- Fix exception detection in DAV client when using Sabre\DAV\Client
- Added setETag() on Node instead of using the static FileSystem
- Also preload tags/props when depth is infinity
Some code paths called the `normalizePath` functionality with types other than a string which resulted in unexpected behaviour.
Thus the function is now manually casting the type to a string and I corrected the usage in list.php as well.
