-
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
High level file locking #16237
High level file locking #16237
Conversation
|
@karlitschek looks like we have to talk on how to continue with this |
76 filing unit tests - that's a statement
|
I guess it's everything related to sharing ? Since sharing is the one part where storages go back to view level (which shouldn't be allowed!) |
yes - this is the root of all evil - trash and/or version do the same afaik. This smells like bigger reengineering - time line is of question. |
* @throws \OCP\Lock\LockedException | ||
*/ | ||
public function acquireLock($path, $type, ILockingProvider $provider) { | ||
$provider->acquireLock($this->getId() . '::' . $path, $type); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to add a utility method to create the lock ids based on getId() + path. This way it can be reused, the format is enforced and also can potentially be used for unit testing too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that the provider's interface is expecting a "$path" as argument, but here what we're passing is more of a key.
Maybe at some point we should rename the locking provider's argument to "$key" then to make it more generic.
Found an easier way to not go trough the view from the shared storage without doing the full refactor (which we still should do for 8.1): #16284 Trash has a similar issue, will make separate PR for that |
@@ -420,6 +421,13 @@ public function __construct($webRoot) { | |||
$this->getLogger() | |||
); | |||
}); | |||
$this->registerService('LockingProvider', function (Server $c) { | |||
/** @var \OC\Memcache\Factory $memcacheFactory */ | |||
$memcacheFactory = $c->getMemCacheFactory(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need the config switch to disable this by default. Maybe provide a NoopLockingProvider ?
And also what happens if memcache isn't available/configured ? We should probably disable locking in that case. (we could add a warning on the admin page later if the config says "I want locking" but memcache is missing)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also see #11804 (comment) for my and @butonic's considerations of using a memory cache that does not guarantee availability. MemcacheFactory uses the distributed cache which can also be memcached
|
@@ -629,6 +637,9 @@ public function rename($path1, $path2) { | |||
$internalPath1 = $mount1->getInternalPath($absolutePath1); | |||
$internalPath2 = $mount2->getInternalPath($absolutePath2); | |||
|
|||
$this->lockFile($path1, ILockingProvider::LOCK_EXCLUSIVE); | |||
$this->lockFile($path2, ILockingProvider::LOCK_EXCLUSIVE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If say we already locked $path1, but $path2 cannot be locked. We'll probably get an exception ? We should unlock $path1 in the exception/finally handler
How about files outside of "files", will they be locked too as per #11804 (comment) ? And exclude "cache" and "files_encryption" maybe. |
I already ticked a few of the items this PR covers here: #11804 (comment) |
|
@icewind1991 I enabled memcached locally, then merged #16284 into this branch locally, ran the unit tests: a lot of sharing tests still fail when running everything, but pass when run individually. I think there might still be some tests that do not clean up properly. Maybe we need to add a "clear all locks" in the TestCase's tearDown. |
either this or provide a mock locking provider that just caches key/values locally, and provides a method to clear itself. |
For Sabre to be able to return the proper error code instead of 500, the LockedException is now rethrown as FileLocked exception in the Sabre connector
@owncloud-bot retest this please |
@icewind1991 this is pointless - jenkins pull request analyser cannot recover ... in addition unit test fail |
A new inspection was created. |
so everything passes on jenkins? @DeepDiver1975 |
@PVince81 afaik there are no regressions in the TODO's you listen, shall we merge this and take care of those separately? |
I was ok to merge this a while ago: #16237 (comment) |
Ok, can we have the final +1 with the latest changes (ce04cf6 mostly) |
Yes - unit test are fine on this branch |
👍 |
1 similar comment
👍 |
Let me move the checkboxes into a separate ticket |
awesome - THX |
Raised here: #16664 I didn't raise separate tickets yet because many already exist as ticket, I added them to that "summary" ticket. I also moved the tests. |
Currently explodes share unit tests.From what I can tell they explode because the view lock the files, call the shared storage, which in turn calls the view, causing the locking logic to be called again.#12086 Should fix that but is not something we can do for 8.1cc @PVince81 @DeepDiver1975