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

Fix VFS crash and false conflict on local new. #3449

Merged

Conversation

allexzander
Copy link
Contributor

Signed-off-by: allexzander blackslayer4@gmail.com

This should do it. Just need to test a couple of times more and maybe come up with some additional scenarios...
Having said that, it works well now when creating new folder and still works as expected when renaming on 2 clients.

Copy link
Collaborator

@mgallien mgallien left a comment

Choose a reason for hiding this comment

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

Works for me but please see my comments

const bool isFilePlaceHolder = !localEntry.isDirectory && _discoveryData->_syncOptions._vfs->isDehydratedPlaceholder(_discoveryData->_localDir + path._local);

// either correct availability, or a result with error if the folder is new or otherwise has no availability set yet
const auto folderAvailability = localEntry.isDirectory ? _discoveryData->_syncOptions._vfs->availability(path._local) : Vfs::AvailabilityError::NoSuchItem;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I have been having an hard time understanding what is being done in this line
I understand that we are using some implicit conversion of OCC::Result but I really wonder why we even have those implicit conversions ?
Can you please make it explicit here ?
I was really wondering why the enum value could be used in boolean context

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was really wondering why the enum value could be used in boolean context

@mgallien I guess this is by the design of Result and enums. But yeah, readability could use some improvement.

// either correct availability, or a result with error if the folder is new or otherwise has no availability set yet
const auto folderAvailability = localEntry.isDirectory ? _discoveryData->_syncOptions._vfs->availability(path._local) : Vfs::AvailabilityError::NoSuchItem;

const auto folderPinState = localEntry.isDirectory ? _discoveryData->_syncOptions._vfs->pinState(path._local) : PinState::Unspecified;
Copy link
Collaborator

Choose a reason for hiding this comment

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

same comment about the implicit conversion


const auto folderPinState = localEntry.isDirectory ? _discoveryData->_syncOptions._vfs->pinState(path._local) : PinState::Unspecified;

if (!isFilePlaceHolder && !folderAvailability && !folderPinState) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

see my previous comment, I would have an hard time explaining what this check is doing
please make it more obvious such that a comment would not be needed

@allexzander
Copy link
Contributor Author

Works for me but please see my comments

@mgallien I am using more explicit code now. The reason implicit conversion works is because Result is implemented as a union and it also implements operator bool, so, it can be implicitly checked for validity. I have added a method to allow explicit chek for no-error.

@allexzander allexzander marked this pull request as ready for review June 22, 2021 08:43
@allexzander allexzander force-pushed the bugfix/fix-vfs-crash-and-false-conflict-on-local-new branch from 937eb1a to 5ed1e87 Compare June 22, 2021 08:47
@allexzander allexzander requested a review from mgallien June 23, 2021 05:46
Copy link
Collaborator

@mgallien mgallien left a comment

Choose a reason for hiding this comment

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

could you reduce the scope of the change to just fix the case of directory creation or write the list of scenario needed to test that change

@@ -896,46 +896,68 @@ void ProcessDirectoryJob::processFileAnalyzeLocalInfo(
auto postProcessLocalNew = [item, localEntry, path, this]() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I fail to understand why we need such complexity here when owncloud client is much simple https://github.com/owncloud/client/blob/master/src/libsync/discovery.cpp#L837*
I am under the impression that this shows that the fixes are being done at the wrong place

Copy link
Collaborator

Choose a reason for hiding this comment

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

after all that code was added to perform a last chance clean up of placeholder files that should not be present and we are now doing a lot of stuff needing comment to be understood
we should simplify or we will end up with code that we can no longer understand and maintain

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I fail to understand why we need such complexity here when owncloud client is much simple https://github.com/owncloud/client/blob/master/src/libsync/discovery.cpp#L837*
I am under the impression that this shows that the fixes are being done at the wrong place

@mgallien I am pretty sure, OwnCloud would have the same problem happening. It is just, nobody complaint about simultaneous renaming/moving of virtual files/folders.

@allexzander
Copy link
Contributor Author

@allexzander allexzander requested a review from mgallien June 29, 2021 08:14
const bool isFilePlaceHolder = !localEntry.isDirectory && _discoveryData->_syncOptions._vfs->isDehydratedPlaceholder(_discoveryData->_localDir + path._local);

// either correct availability, or a result with error if the folder is new or otherwise has no availability set yet
const auto folderAvailability = localEntry.isDirectory ? _discoveryData->_syncOptions._vfs->availability(path._local) : Vfs::AvailabilityResult(Vfs::AvailabilityError::NoSuchItem);
Copy link
Collaborator

Choose a reason for hiding this comment

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

if I understand correctly your modification, this should be called folderPlaceHolderAvailability ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mgallien done

Signed-off-by: allexzander <blackslayer4@gmail.com>
Signed-off-by: allexzander <blackslayer4@gmail.com>
…ne-only folder based on its pinState.

Signed-off-by: allexzander <blackslayer4@gmail.com>
Signed-off-by: allexzander <blackslayer4@gmail.com>
Signed-off-by: allexzander <blackslayer4@gmail.com>
@allexzander allexzander force-pushed the bugfix/fix-vfs-crash-and-false-conflict-on-local-new branch from 086fed8 to 99f6e82 Compare July 1, 2021 08:59
@allexzander allexzander requested a review from mgallien July 1, 2021 09:00
@nextcloud-desktop-bot
Copy link

AppImage file: Nextcloud-PR-3449-99f6e822906ba47670593dc91ee1a601ee0fcdcc-x86_64.AppImage

To test this change/fix you can simply download above AppImage file and test it.

Please make sure to quit your existing Nextcloud app and backup your data.

@allexzander allexzander merged commit dca7b8d into master Jul 1, 2021
@allexzander allexzander deleted the bugfix/fix-vfs-crash-and-false-conflict-on-local-new branch July 1, 2021 10:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants