-
Notifications
You must be signed in to change notification settings - Fork 806
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
Conversation
20f8fe5
to
d27c906
Compare
src/common/filesystembase.cpp
Outdated
@@ -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")); |
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 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.
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.
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.
You may also want to add
exclude.lst
as a exclude file. Seesrc/libsync/conifgfile.cpp:362
.
Good idea.
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 it might be a good idea to create a named constant for these filenames.
Could do, but, where should I put that constant?
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.
@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.
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.
@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.
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.
@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 :)
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.
@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.
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.
@allexzander No meant that you can use the constants everywhere. Because isExclude()
will also be used everywhere right?
/rebase |
d27c906
to
524e4b2
Compare
@mgallien |
not yet bu the debian part of the pipeline had failed hence why I did that to get a clean state |
83d6e00
to
db87558
Compare
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.
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 ?
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.
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.
Hard to say. |
src/common/filesystembase.cpp
Outdated
@@ -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")); |
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 guess I do not understand why endsWith
instead of an equal comparison ?
we are going to accept names we may not want
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 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.
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.
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
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.
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
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.
@mgallien makes sense, will do that
de99c5b
to
3957d35
Compare
/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>
c73f9ec
to
d6ddf59
Compare
AppImage file: Nextcloud-PR-3390-d6ddf595f8d7d3b3995ed784ca383e9c8cc789fa-x86_64.AppImage |
/backport to stable-3.2 |
Signed-off-by: allexzander blackslayer4@gmail.com
This should fix #3318