* Properly expire ext storage versions
System-wide external storages have no real owner so the current user is
used as owner. However when running cron.php there is no current user,
so no expiry can be done.
This fix adds an user argument to the expire() function to tell for
which user to expire files. This information is anyway always available
now through the expire command job.
* Move version expire setupFS into the expire function
* Add comment about not tearing down in version Storage::expire()
Signed-off-by: Lukas Reschke <lukas@statuscode.ch>
When calling `\OC\Files\View::copy` we should also keep the version to ensure that the file will always have the correct version attached and can be successfully decrypted.
To test this the following steps are necessary (from https://github.com/owncloud/core/issues/22781#issuecomment-191328982):
1. setup a new ownCloud 9.0 beta2
2. enable encryption
2. upload a docx (5.7MB large)
3. upload the same file again and overwrite the existing file
4. I can download the original file and the first version
5. I restore the first version
6. restored version can no longer be downloaded with the error described above
The manual cache operation in `\OCA\Files_Versions\Storage` is unfortunately necessary since `\OCA\Files_Versions\Storage::copyFileContents` is not using `\OCP\Files\Storage::moveFromStorage` in the case when an object storage is used. Due to the workaround added in 54cea05271 the stream is directly copied and thus bypassing the FS.
$view->getUidAndFilename($filename); returns the federated cloud id in case of
a federated share. But in this case we need the local user who "owns" the file
which is the current logged in user in case of a federated share
* versionSize is calculated anyway in the expire job - > dropped
* offset/neededSpace was needed for expiry before the file is moved to the versions -> now this is included already in the currently used space because the expiry job is defered to a point in time after the version creation
* fixes#21108
Currently the `getPath` methods returned `NULL` in case when a file with the specified ID does not exist. This however mandates that developers are checking for the `NULL` case and if they do not the door for bugs with all kind of impact is widely opened.
This is especially harmful if used in context with Views where the final result is limited based on the result of `getPath`, if `getPath` returns `NULL` PHP type juggles this to an empty string resulting in all possible kind of bugs.
While one could argue that this is a misusage of the API the fact is that it is very often misused and an exception will trigger an immediate stop of execution as well as log this behaviour and show a pretty error page.
I also adjusted some usages where I believe that we need to catch these errors, in most cases this is though simply an error that should hard-fail.
Bjoern Schiessle
Joas Schilling
Morris Jobke
Lukas Reschke
Vincent Petry
Roeland Jago Douma
Jörn Friedrich Dreyer
Thomas Müller
Carlos Damken
Lukas Reschke
Victor Dubiniuk
Joas Schilling
Joas Schilling
Bjoern Schiessle
Arthur Schiwon
Thomas Müller
Robin Appelman
Scrutinizer Auto-Fixer