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

VFS freeze fix. Treat .sync-exclude.lst as a non-virtual file always. #3390

Merged
merged 4 commits into from
Jun 8, 2021

Conversation

allexzander
Copy link
Contributor

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

This should fix #3318

@allexzander allexzander force-pushed the bugfix/syncexclude-dehydration-freeze branch from 20f8fe5 to d27c906 Compare June 1, 2021 18:09
@@ -480,6 +480,11 @@ bool FileSystem::isLnkFile(const QString &filename)
return filename.endsWith(QLatin1String(".lnk"));
}

bool FileSystem::isExcludeFile(const QString &filename)
{
return filename.endsWith(QLatin1String(".sync-exclude.lst"));
Copy link

Choose a reason for hiding this comment

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

I guess @mgallien will say better use QStringLiteral :)

You may also want to add exclude.lst as a exclude file. See src/libsync/conifgfile.cpp:362. Also it might be a good idea to create a named constant for these filenames.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

QStringLiteral

@FlexW

Goot catch. It's a leftover. Gonna change it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@FlexW

You may also want to add exclude.lst as a exclude file. See src/libsync/conifgfile.cpp:362.

Good idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@FlexW

Also it might be a good idea to create a named constant for these filenames.

Could do, but, where should I put that constant?

Copy link

Choose a reason for hiding this comment

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

@allexzander How about src/csync/csync_exclude.h? May not be optimal but thats were it originally comes from I guess. src/common/filesystembase.h might also be a fit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@FlexW I've checked both suggestions and neither suits well. src/common/filesystembase.h is not really a good choice because it is a helper file that is not supposed to store implementation details of the sync engine. src/csync/csync_exclude.h is also not the best place considering I will have then to import a part of sync engine into a helper class src/common/filesystembase.h which is in a common folder. I don't like having cross-dependencies. What I could do is - to add a separate header into a common folder. That header would then contain all the common constants. The problem is, however, I already have that header in another PR and don't want to create conflicts later. So, what I am thinking is - I should keep these file names hard-coded for now, and then, factor them out into a separate common header later in a separate PR.

Copy link

Choose a reason for hiding this comment

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

@allexzander At least you put sync engine detail functions into src/common/filesystembase.h with isExclude(). So I don't see why adding these constants here might be not a fit :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@FlexW You mean just adding constants into filesystembase and then using them just there? I've been thinking about something more common, like, having a header file that I can include into filesystembase and other places where this same .sync-exclude.lst is encountered, to make sure we have these constants all in one place.

Copy link

Choose a reason for hiding this comment

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

@allexzander No meant that you can use the constants everywhere. Because isExclude() will also be used everywhere right?

@allexzander allexzander requested review from mgallien and camilasan June 2, 2021 08:06
@mgallien mgallien requested a review from er-vin June 2, 2021 08:10
@mgallien
Copy link
Collaborator

mgallien commented Jun 2, 2021

/rebase

@github-actions github-actions bot force-pushed the bugfix/syncexclude-dehydration-freeze branch from d27c906 to 524e4b2 Compare June 2, 2021 08:12
@allexzander
Copy link
Contributor Author

/rebase

@mgallien
Were you going to merge it?

@mgallien
Copy link
Collaborator

mgallien commented Jun 2, 2021

/rebase

@mgallien
Were you going to merge it?

not yet bu the debian part of the pipeline had failed hence why I did that to get a clean state

@allexzander allexzander requested a review from FlexW June 2, 2021 10:45
@allexzander allexzander force-pushed the bugfix/syncexclude-dehydration-freeze branch from 83d6e00 to db87558 Compare June 3, 2021 07:23
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.

So, if I understand correctly we are letting some files be synced within the sync directory without making them placeholders because we want to have them always there.
Will not that cause problems with other parts of CfApi or sync engine ?
Do we already have cases where we do that ?

@allexzander
Copy link
Contributor Author

@mgallien

So, if I understand correctly we are letting some files be synced within the sync directory without making them placeholders because we want to have them always there.

Yes. In fact, we not just always want them always there because we don't want them to be virtual, it is more of a way sync engine works. When we request dehydration, those .sync-exclude.lst files are marked for dehydration, but, during the sync, it is required that they are on disk and they are attempted to get opened and parsed during the sync. This brings us to the infinite loop - we want to dehydrate a .sync-exclude.lst, but, at the same time, we want them to be hydrated. This leads to an app freezing.

Do we already have cases where we do that ?

Not that I am aware of. We have some files that we exclude from sync completely though due to VFS. We always exclude .lnk files, but, we can't exclude .lst files as they are affecting the folders' configuration in terms of files excluded from sync, so, we can only make them non-virtual, and we can't exclude them completely.

Will not that cause problems with other parts of CfApi or sync engine ?

Hard to say.

@allexzander allexzander requested a review from mgallien June 7, 2021 11:47
@@ -480,6 +480,11 @@ bool FileSystem::isLnkFile(const QString &filename)
return filename.endsWith(QLatin1String(".lnk"));
}

bool FileSystem::isExcludeFile(const QString &filename)
{
return filename.endsWith(QStringLiteral("sync-exclude.lst")) || filename.endsWith(QStringLiteral("exclude.lst"));
Copy link
Collaborator

Choose a reason for hiding this comment

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

I guess I do not understand why endsWith instead of an equal comparison ?
we are going to accept names we may not want

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 guess I do not understand why endsWith instead of an equal comparison ?
we are going to accept names we may not want

@mgallien My plan was to also catch nested sync-exclude.lst, but, I will remove it. If someone reopens this issue later with nested sync-exclude.lst causing problems, I will then just bring endsWith back.

Copy link
Collaborator

Choose a reason for hiding this comment

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

In that case, you can do the comparison such that you are sure not to catch filenames like test.exclude.lst but accept test/.exclude.lst or .exclude.lst

Copy link
Collaborator

Choose a reason for hiding this comment

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

or if I did not understood correctly accept:

  • .sync-eclude.lst
  • test/.sync-exclude.lst

but refuse

  • test.sync-exclude.lst
  • test/rover.sync-exclude.lst

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 makes sense, will do that

@allexzander allexzander force-pushed the bugfix/syncexclude-dehydration-freeze branch from de99c5b to 3957d35 Compare June 8, 2021 06:45
@allexzander allexzander requested a review from mgallien June 8, 2021 07:20
@mgallien
Copy link
Collaborator

mgallien commented Jun 8, 2021

/rebase

Signed-off-by: allexzander <blackslayer4@gmail.com>
Signed-off-by: allexzander <blackslayer4@gmail.com>
Signed-off-by: allexzander <blackslayer4@gmail.com>
Signed-off-by: allexzander <blackslayer4@gmail.com>
@github-actions github-actions bot force-pushed the bugfix/syncexclude-dehydration-freeze branch from c73f9ec to d6ddf59 Compare June 8, 2021 09:25
@nextcloud-desktop-bot
Copy link

AppImage file: Nextcloud-PR-3390-d6ddf595f8d7d3b3995ed784ca383e9c8cc789fa-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 c59e3c4 into master Jun 8, 2021
@allexzander allexzander deleted the bugfix/syncexclude-dehydration-freeze branch June 8, 2021 09:44
@allexzander
Copy link
Contributor Author

/backport to stable-3.2

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.

Nextcloud 3.2.1stable-Win64: Hung on client start
4 participants