- uses PUT method with jquery.fileupload for regular and public file
lists
- for IE and browsers that don't support it, use POST with iframe
transport
- implemented Sabre plugin to handle iframe transport and redirect the
embedded PUT request to the proper handler
- added RFC5995 POST to file collection with "add-member" property to
make it possible to auto-rename conflicting file names
- remove obsolete ajax/upload.php and obsolete ajax routes
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Enhanced the REPORT method on the Webdav endpoint and added a
"oc:favorite" filter rule. When set, it will return a flat list of
results filtered with only favorite files.
The web UI was also adjusted to use this REPORT method instead of the
private API endpoint.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* Use DI to load console commands from the apps - class name to be defined in the info.xml
* Load commands from info.xml
* Fix unit test
* Allow Di magic for IMountManager
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The new admin page broke the updating of the max upload size. This is
due to very old code there.
* Now update is done in the background using js
* Added proper route+controller to update
Fixes#994
* Move background job registration of Federation to info.xml
* Move background registration of Files app to info.xml
* Move background job registration of files_sharing to info.xml
* Move background job registration of files_trashbin to info.xml
* Move background job registration of files_versions to info.xml
* Move background job registration from user_ldap to info.xml
add checkbox to toggle show/hide hidden files
persist show hidden setting
fix settings menu layout
test ApiController::showHiddenFiles
don't show hidden files by default
Store config in Backbone model and inject it into FileList
Filter files only temporarily when rending the file list
Fix file rename validation
* fixes#22819
The old way fired a DELETE statement on each destruction of the
DBLockingProvider. Which could cause a lot of queries. It's enough
to run this every 5 minutes in a background job, which in the end
could result in file locks that exists 5 minutes longer - in the
worst case and for not properly released locks.
This makes the DB based locking a lot more performant and could
result in a similar performance to the Redis based locking provider.
Whenever a file was deleted (also from trash), the tag mapping is
pointing at a fileid that doesn't exist any more.
This cleanup job will delete such orphaned mapping entries.
* Register OCP\Capability\IManager at DIContainer
* Add register capabilities to appframework
* Register capabilities in DI way
* Make unit test pass again
* Remove CapabiltiesManager from OCP
In case encryption was not enabled, we accidently set encrypted = 1 for
files inside mount points, since 8.1.0. This breaks opening the files in
8.1.1 because we fixed the code that checks if a file is encrypted.
In order to fix the file, we need to reset the flag of the file. However,
the flag might be set because the file is in fact encrypted because it was
uploaded at a time where encryption was enabled.
So we can only do this when:
- Current version of ownCloud before the update is 8.1.0 or 8.2.0.(0-2)
- Encryption is disabled
- files_encryption is not known in the app config
If the first two are not the case, we are save. However, if files_encryption
values exist in the config, we might have a false negative here.
Now if there is no file with unencrypted size greater 0, that means there are
no files that are still encrypted with "files_encryption" encryption. So we
can also safely reset the flag here.
If this is not the case, we go with "better save then sorry" and don't change
the flag but write a message to the ownCloud log file.
This removes the hard-dependency on output buffering as requested at https://github.com/owncloud/core/issues/16013 since a lot of distributions such as Debian and Ubuntu decided to use `4096` instead of the PHP recommended and documented default value of `off`.
However, we still should encourage disabling this setting for improved performance and reliability thus the setting switches in `.user.ini` and `.htaccess` are remaining there. It is very likely that we in other cases also should disable the output buffering but aren't doing it everywhere and thus causing memory problems.
Fixes https://github.com/owncloud/core/issues/16013
This Pull Request introduces a SabreDAV plugin that will block all older clients than 1.6.1 to connect and sync with the ownCloud instance.
This has multiple reasons:
1. Old ownCloud client versions before 1.6.0 are not properly working with sticky cookies for load balancers and thus generating sessions en masse
2. Old ownCloud client versions tend to be horrible buggy
In some cases we had in 80minutes about 10'000 sessions created by a single user. While this change set does not really "fix" the problem as 3rdparty legacy clients are affected as well, it is a good work-around and hopefully should force users to update their client
Reasoning:
- a WebDAV server is not required to implement locking support
- WebDAV Locking is know to break the sync algorithm
- the current lock implementation is known to be broken (locks are not moved if a file is moved, locks on shared files don't work)
- 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
Added oc:tags and oc:favorites in PROPFIND response.
It is possible to update them with PROPPATCH.
These properties are optional which means they need to be requested
explicitly
The codepath for generating the favicons iterates through subnodes and if one of those nodes is unavailable is throwing a 503 exception. Since these favicons don't have any use except of "making a tool for developers looking nicer" I consider it feasible to remove them.
Joas Schilling
Lukas Reschke
Vincent Petry
Thomas Müller
Roeland Jago Douma
Arthur Schiwon
William Bargent
Robin Appelman
Lukas Reschke
Joas Schilling
Christoph Wurst
Morris Jobke
Joas Schilling
Stefan Weil
Thomas Müller
Arthur Schiwon
Roeland Jago Douma
Robin Appelman
Bjoern Schiessle
Jenkins for ownCloud
Jörn Friedrich Dreyer