Currently if a user does not replace the .htaccess file with the new update this can lead to serious problems in case Apache is used as webserver.
This commit adds the version to the .htaccess file and the update routine fails in case not the newest version is specified in there. This obviously means that every release has to update the version specified in .htaccess as well. But I see no better solution for it.
Conflicts:
lib/private/updater.php
The update routine tries to test the database migration before actually performing the update.
However, this will fail hard if the schema has changed (for example an unique key has been added). App developers can convert the DB in preupdate.php, however it is not called before and therefore the update fails.
This actually breaks ownCloud updates from ownCloud 6 to ownCloud 7 when the files_antivirus app is enabled.
If an app upgrade failed, the core version will not be increased either
in the database. This will re-display the update page and make it
possible to redo the apps upgrade.
Note that any core repair routine must take into account that an update
might need to be redone again even though the core's DB state is already
the one of the new version.
The updater is using "before update" repair steps and "regular" repair
steps.
The "regular" repair steps are also used by the CLI tool.
Currently no steps exist but can be added later in the static methods in
the \OC\Repair class.
Added unit test to test messaging, error and exception cases.
adding auto increment/PK to table files_trash
adding PK to table ldap_user_mapping and ldap_group_members
adding PK to table ldap_group_mapping
truncate permissions table to allow smooth creation of primary key
adding unit test for creating an auto increment column on a table which already contains data
remove unneeded table files_trashsizes
fix unit test
no need to truncate *PREFIX*permissions
On Oracle adding auto increment columns is not working out of the box - Oracle migrations are to be done manually
Added "dry run" argument to only run the update simulation.
Added argument to disable migration (useful for bigger setups where
table duplication would take too much space)
In environments where the data folder is mount from another partition,
it is important to check that the data folder we see is actually the
real one. If the mount failed for some reasons, this fix will make
ownCloud temporarily unavailable instead of causing unpredictable
behavior.
1. We're maintaining the same code twice which leads inevitably to problems as this one. The createHtaccess routine is only used to use the correct paths to the 404 and 403 document.
2. Updating the ownCloud instance as described in our documentation (`Delete everything from your ownCloud installation directory, except data and config.`) will break the links to the ErrorDocuments anyways and show the default error handlers if ownCloud is not installed in the root directory.
