Skip to content
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

keep a read lock while scanning a file or folder #16729

Merged
merged 5 commits into from
Jun 17, 2015

Conversation

icewind1991
Copy link
Contributor

Note that this does not prevent concurrent scanners, only stops the file or folder being changed while scanning

For #16664

cc @DeepDiver1975 @PVince81

@PVince81
Copy link
Contributor

PVince81 commented Jun 3, 2015

If this can fix the data loss issue #13391 (comment) then it already rocks

@icewind1991
Copy link
Contributor Author

If the issue is not fixed with just this PR we could add a lock for the cache next to the current lock to prevent partial updated cache data being returned from PROPFIND and friends while the cache is being updated

@PVince81
Copy link
Contributor

PVince81 commented Jun 3, 2015

  • BUG: upload in root folder with sync client always gives "locked" error (subdirs seem fine)

@PVince81
Copy link
Contributor

PVince81 commented Jun 3, 2015

Testing #13391 (comment)
While this PR makes it a little less likely to happen, it still happened again: files lost.

It also seemed that the sync client hung in the discovery phase, maybe some changes will be required there as well to make sure it just continues.

@PVince81
Copy link
Contributor

PVince81 commented Jun 9, 2015

@icewind1991 any update on this in regards to fixing #13391 ?

I noticed in my analysis yesterday that we need to be careful what data is returned to the client.
So even if the scanner would find that the folder on-disk has disappeared, it should not remove it from the result list if it is locked, else the client might delete it...

@icewind1991
Copy link
Contributor Author

The failure was caused by the trashbin needing the fileinfo in the wrapper for shared files which can triger a scan and run into a locking problem.

I've worked around this by making sure the scanning happens in the pre-hook instead of the unlink operation itself.
Not the cleanest solution but all I can come up with at the moment

@icewind1991
Copy link
Contributor Author

upload in root folder with sync client always gives "locked" error (subdirs seem fine)

@PVince81 can you retest?

@PVince81
Copy link
Contributor

Upload to root folder works now.

* @param array $params
*/
public static function ensureFileScannedHook($params) {
self::getUidAndFilename($params['path']);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weird magic ?
explain

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ensures that if the file needs to be scanned it's scanned during the pre-hook and not the actual delete operation (where it's write locked)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

=> add a comment // triggers scan indirectly or something along these lines

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@icewind1991 please add comment to the code as requested - THX

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Expanded the phpdoc

@PVince81
Copy link
Contributor

This does not fix the problem here #13391

Maybe it fixes another one from the list #16664 ?

@icewind1991
Copy link
Contributor Author

@DeepDiver1975 @MorrisJobke please review

@PVince81
Copy link
Contributor

How did you test this ? Which one of the many issues does this fix ?

@icewind1991
Copy link
Contributor Author

It should fix issues where a file is deleted/renamed while the file is being scanned.

To test:

  • Add a sleep in scanFile (after the call to getData)
  • trigger a scan on an existing file from the cli ./occ files:scan --path /test/files/folder/asd.jpg
  • rename the file trough the web interface while the scan is running

Without this patch the rename completes and both the old an new file will show up in the web interface, with this patch the rename fails with a locked exception

@PVince81
Copy link
Contributor

Cool thanks, I'll have a try.

@PVince81
Copy link
Contributor

Works 👍

(side note: I completelty forgot that we had the --path option)

@PVince81 PVince81 added this to the 8.1-current milestone Jun 12, 2015
@icewind1991
Copy link
Contributor Author

@MorrisJobke @DeepDiver1975 please review, this is blocking some other locking work I would like to do

@@ -237,12 +239,11 @@ public function put($data) {
}
}
$this->refreshInfo();
$this->fileView->unlockFile($this->path, ILockingProvider::LOCK_SHARED);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks somehow weird. The lock seems to be never unlocked when an error between the lock and unlock happens. Is this valid nevertheless?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If an exception happens the unlock will be handled by the shutdown handler, since any error here ends the request there is no need to unlock the file before the end of the request

@DeepDiver1975
Copy link
Member

@icewind1991 we need a rebase here - THX

@@ -83,6 +89,7 @@ public function __construct(\OC\Files\Storage\Storage $storage) {
$this->storageId = $this->storage->getId();
$this->cache = $storage->getCache();
$this->cacheActive = !Config::getSystemValue('filesystem_cache_readonly', false);
$this->lockingProvider = \OC::$server->getLockingProvider();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

inject?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cant without breaking changes to the storage api :(

@scrutinizer-notifier
Copy link

A new inspection was created.

@ghost
Copy link

ghost commented Jun 15, 2015

🚀 Test PASSed.🚀
chuck

@icewind1991
Copy link
Contributor Author

@DeepDiver1975 can this be merged?

@PVince81
Copy link
Contributor

My 👍 still applies.

Blocks #16963.
Please review promptly.

@PVince81
Copy link
Contributor

@nickvergessen maybe ?

@DeepDiver1975
Copy link
Member

👍

DeepDiver1975 added a commit that referenced this pull request Jun 17, 2015
keep a read lock while scanning a file or folder
@DeepDiver1975 DeepDiver1975 merged commit d2305f2 into master Jun 17, 2015
@DeepDiver1975 DeepDiver1975 deleted the scanner-read-lock branch June 17, 2015 09:52
@PVince81
Copy link
Contributor

Regression: #16998

@lock lock bot locked as resolved and limited conversation to collaborators Aug 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants