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

avoid running OC\Files\Cache\Updater::update double #18754

Closed
wants to merge 1 commit into from
Closed

avoid running OC\Files\Cache\Updater::update double #18754

wants to merge 1 commit into from

Conversation

individual-it
Copy link
Member

when the file is touched the updater already run, so no need to
run it again.
In my quick testing this saves around 25% time when uploading a lot of small files #7072

when the file is touched the updater already run, so no need to
run it again.
@scrutinizer-notifier
Copy link

A new inspection was created.

@icewind1991
Copy link
Contributor

Good catch, but when combined with #18753 this will break updating the folder size on dav upload

@individual-it
Copy link
Member Author

Yes both fixes are alternatives at the moment.
This one safes more time the #18753 looks for me as the better design.
We could have both if we introduce a "doNotUpdate" switch for touch() or move the $updateType array some levels higher and pass it down till it finally checked in update()
But that's sound a little bit messy to me

@individual-it
Copy link
Member Author

Actually thinking again about it, both fixes can go very well together.
If we implement updateMtime($storage, $internalPath),updateFolderSize($storage,$internalPath) and update($path, $time = null) as I'm proposing here #18753 (comment)
then touch() can run updateMtime($storage, $internalPath) and here we check if touch() was already called.
If yes only updateFolderSize($storage, $internalPath) need to be called here. If not update($path, $time = null) will be called and call updateMtime($storage, $internalPath) and updateFolderSize($storage, $internalPath) itself

@individual-it
Copy link
Member Author

closing in favour of #18753

@lock lock bot locked as resolved and limited conversation to collaborators Aug 10, 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.

None yet

3 participants