Menu
▾
▴
#658 File changes during Invitation corrupts session
Steps to reproduce:
1. Alice shares a partial project with Bob
2. Alice adds Carl to Session
3. Carl accepts (project negotiation still running)
4. Bob modifies a shared file
5. -> for every key stroke of Bob Alice gets asked about if she wants to partial share the file (on top of that no information about the file to be shared)
-> Session gets inconsistent without the watchdog being able to detect.
Solution is pretty "simple". Disallow any modification on the files while sync. is in progress. Kick every user from the session who still tries to modify files. We are doing this, but it seems we are not doing it right. You can even cancel your read-only access during sync.
It seems that these Activities are supposed to be queued (have a look at SarosSession.java lines 698 - 799), but something goes wrong. It was so much easier when we were sure that we eventually will have the whole project...
Priority level 9 was far to high.
Bug still exists in Saros 12.3.30 and current master (Git 0b7b758) --> removed Group.
Priority level 5 was far to low.
As the participants are not blocked during the whole sync. process, it is common to assume that modifications made during sync. will be applied after sync. is done, thus representing the normal workflow.
> Priority level 5 was far too low.
Please don't be silly. Since we don't have a strict scheme to assign bugs to all 9 priority levels that Sourceforge offers, a change from "5" to "6" is a waste of your time.
> As the participants are not blocked during the whole sync. process ...
Aren't they? I think that there are phases in the sync. process in which the users are indeed blocked. But it doesn't matter: As long as there remains time slots in which changes are possible and these changes can lead to undetectable inconsistencies, this issue remains relevant.
> Thus representing the normal workflow.
Yes, but only under the two preconditions of more than two participants and the usage of partial sharing. (These two preconditions were the reason to lower the priority from 9 to 5.)
We have a scheme, http://www.saros-project.org/BugTracking
But it seems that it is ignored to many times.
The users are only blocked while the archives are created, but no when the archive is transmitted. I think this problem does also apply to full shared projects.
There is also no time slot, because stopping a user does not prevent him to add / delete files.
Saros is using P2P and this can make this problem even worse. A, B, C.
B adds a new file, A gets the new file, C also, but how should C handle this file ?
Watchdog will only detects the missing file, if it will opened in an editor at host side.
>> we don't have a strict scheme to assign bugs to all 9 priority levels that Sourceforge offers, a change from "5" to "6" is a waste of your time.
> We have a scheme, http://www.saros-project.org/BugTracking
Yes, we have *a* scheme, but there is no consistent description how to tell levels 5 and 6 apart.
I suggest to wait for starroli's changes on this topic.
Planned for Release 12.7.27
e4a84c54038bed452925078506c4622275a131f9
e4a84c54038bed452925078506c4622275a131f9