Uh oh!
There was an error while loading. Please reload this page.
properly lock the target file on dav upload when not using part files - #9473
Conversation
| throw new FileLocked($e->getMessage(), $e->getCode(), $e); | ||
| } | ||
| throw new FileLocked($e->getMessage(), $e->getCode(), $e); | ||
| } |
There was a problem hiding this comment.
Why? IMO it makes sense to split it. 🤔
There was a problem hiding this comment.
I meant the if at
https://github.com/nextcloud/server/pull/9473/files#diff-be504dc886734275f06114e4306fa215R203
and
https://github.com/nextcloud/server/pull/9473/files#diff-be504dc886734275f06114e4306fa215R217
The try catch need to be split sure ;)
8b854ee to
891460aCompareCodecov Report
@@ Coverage Diff @@## master #9473 +/- ##
=============================================
- Coverage 51.92% 31.27% -20.66% + Complexity 25769 25746 -23
=============================================
Files 1635 1641 +6 Lines 95434 96518 +1084 Branches 1308 1393 +85 =============================================
- Hits 49557 30182 -19375 - Misses 45877 66336 +20459
|
MorrisJobke
commented
May 16, 2018
Unit tests fail. :/ |
| $partStorage->unlink($internalPartPath); | ||
| if ($needsPartFile) { | ||
| if ($view) { | ||
| $this->emitPreHooks($exists); |
There was a problem hiding this comment.
You ignore the result here now. So if the prehook returns false you should probably also fail right?
There was a problem hiding this comment.
See the unit tests, which fail now due to this.
MorrisJobke
left a comment
There was a problem hiding this comment.
See unit tests and @rullzer's comment.
Signed-off-by: Robin Appelman <robin@icewind.nl>
891460a to
f017f43Compareicewind1991
commented
Jun 11, 2018
Fixed the unit test |
MorrisJobke
commented
Jun 11, 2018
@icewind1991 Does a backport to 13 makes sense or should we skip it? |
icewind1991
commented
Jun 11, 2018
backport makes sense imo |
MorrisJobke
commented
Jun 12, 2018
@icewind1991 Could you prepare the PR? |
While non-partfile storages don't have the file corruption problem on current read/writes (which is why I left this until now) not locking the target file during write can still lead to an inconsistent filecache state because the scanner is not being blocked.