-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Copy file to owner's trash when recipient moves out of share #27042
Conversation
@PVince81, thanks for your PR! By analyzing the history of the files in this pull request, we identified @DeepDiver1975, @stevenbuehner and @bartv2 to be potential reviewers. |
Currently when moving out "test/deletedk.txt" into the root as recipient:
|
It looks like I won't be able to bypass the locking issue from this point of the code. The problem is that the So the only solution is to do the copy in question from within the pre rename hook, in which only a shared lock is applied. |
|
Codecov Report
Continue to review full report at Codecov.
|
327483c
to
47bdc5d
Compare
|
47bdc5d
to
270c30d
Compare
|
|
|
|
It's looking good and also works already.
|
0eea85f
to
5c1238e
Compare
This is now ready for review @jvillafanez @VicDeo @DeepDiver1975 @IljaN |
Tests pass for me locally 😢 |
5c1238e
to
f3f1e3d
Compare
Rebasing as a tentative of luck |
Let's see... maybe I can just register an encryption wrapper in the tests... at least this will bring all tests closer to reality. |
Here we go, the encryption wrapper fixes the test: e22d634 |
I don't see any other change that should be done, so as long as it's working 👍 |
So... now StorageTests pass but TrashbinTest fail again 😢 |
Failure on pgsql now, so much fun:
|
Looks like the source storage id is Need to make sure that the source storage exists in DB before doing this. |
Arghhh, seems there is yet another bug in the FS code. The SharedCache doesn't seem to forward all calls to the underlying cache, so it cannot get its numeric id. |
This seems to fix it, but not sure how dangerous...
I wonder why this wasn't found before... Probably hidden by another bug that cancels it out ? |
Looks like this code was completely wrong. There isn't even a But so far no unit test failed because of this... |
I made a separate PR for this fix with an extra unit test: #27172 |
e22d634
to
47acac7
Compare
I have now cherry-picked the fix from #27172 to this PR here. Let's see if the tests pass first and then make a decision whether to keep the extra fix or not. |
The extra fix has evolved a bit. Waiting for #27172 to be merged then rebase. |
Whenever a share recipient moves files or folders out of the share, make a backup copy in the owner's trash just in case. The metadata stays on the recipient's copy that was moved out.
Because the encryption wrapper does some twisted stuff with methods like moveFromStorage, we need to apply it here to make sure the behavior is close to reality.
47acac7
to
641d3dc
Compare
Rebased to include the final fix from #27172 |
GREEN ! FINALLY GREEN ! After all these struggles. I hope you'll enjoy this enhancement, guys... |
Added to new features of 10.0: https://github.com/owncloud/core/wiki/ownCloud-10.0-Features |
Regression: #27698 |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Description
Whenever a share recipient moves files or folders out of the share,
make a backup copy in the owner's trash just in case.
The metadata stays on the recipient's copy that was moved out.
Related Issue
Fixes #24053 (without activity entry)
Motivation and Context
Solves the case where the recipient is not reachable any more so the owner still has a chance to restore the file.
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist:
TODOs: