Menu
▾
▴
#502 Partial Sharing may not recognize file encoding
Case 1:
− Host changed file encoding (from UTF-8 to ISO-8859-1)
− Invitee got Watchdog Notification about inconsistency in file
− Invitee told Watchdog to recover consistency, but this did not work
− Invitee got still message from watchdog about inconsistency
− Invitee tried out several times to recover file with watchdog, but this did not work → infinite loop
− On both sides (host and invitee) all lines in the file were marked as changed by the other side
− Session had to be restarted
Case 2: when using existing project with modifications
− Sharing a project, invitee already had version of project
− Invitee had some local modifications in one file of the project
− Invitee got invitation from Host, accepted invitation with using his existing project for the session
− After the session was established, the host got a watchdog notification about an inconsistency (the file which was modified in the invitee’s local version of the project)
− But Watchdog was unable to recover consistent version of the file –> infinite loop of watchdog notification and unsuccessful attempt of recovery
I am unable to reproduce the bugs.
For case 2:
My modified file will be overwritten during project synchronisation.
For case 1:
Changing the encoding of the file via Eclipse editor preferences will be reflected to the invitee.
I have never recieved a inconsistency notification.
Please provide more details for analysis.
Tested with latest revision from trunk.
From #2910129:
Eclipse can also freeze on the host side.
Here's a way to reproduce the bug:
A hosts, invites B.
B creates inconsistency.
B tries to sync inconsistency, but drops in the process (client crash).
This can be simulated by terminating Eclipse via Task Manager/kill/etc.
B comes back online within 15 seconds, thus preventing A from timeout.
-> A hangs in a modal dialog, unable to cancel the synchronization.
Both cases are not reproducible using Saros 12.3.30.
The problem still exists. It can be reproduced with the following steps:
1) A and B work together on the same project
2) After closing the session, B changes the file encoding of one of the files in the project
3) A invites B to continue working on the project
4) An inconsitency is detected which can not be resolved
This is not actually a bug of the watchdog.
It seems that the PreferenceManager (which would only work with JDT (why only JAVA ?!)) does not affect the project properly.
I have not done any analyse, but I think that what is going on.
Host send recovered file
Client closes editor, replace the file contents and reopen the editor.
The editor is replacing the line breaks again.
File content is now different from the hosts one (same as before recovery)
Rinse and repeat.
With the partial sharing feature, the encoding settings (file encoding, line delemiter encoding) may be not transfered, because the file that contains the encoding may not be shared. It is also possible to change these settings at runtime. Without the initial settings it is impossible to react on those changes that causes file corruptions because we are unable to restore the original encodings. This will affect the watchdog, as it will never recover any files successfully, because as soon as the file will be reopened, the editor decodes the binary data in a wrong way.
Could not reproduce with current master either.
Disregard last comment. We could reproduce it, however the behaviour is quite heisenbug-ish.
We have test cases for this issue:
http://saros-build.imp.fu-berlin.de/gerrit/#/c/210/3/de.fu_berlin.inf.dpp/test/stf/de/fu_berlin/inf/dpp/stf/test/partialsharing/ShareFilesToProjectsWithDifferentEncodingTest.java
Fix / Hack is already present in the code base but not activated.
See: http://saros-build.imp.fu-berlin.de/gerrit/#/c/200/8/de.fu_berlin.inf.dpp/src/de/fu_berlin/inf/dpp/ui/util/CollaborationUtils.java
After some testing I think it is save to execute the block.
Affected editors are closed during project synchronization (well you can at least reopen them manually ... but I do not think anyone will do this)
be0e4121e3292379e72af8d139484e167621e1e9
@Christian @Arndt: The commit mentioned above is part of the release branch, but this ticket is not pending-fixed. Did you verify the fix?
No, we did not. I don't know why, but this Fix is not in the Changelog.
I am not able to reproduce this with the release/14.10.31 source code. Someone else should prove that to verify the fix.
Could not produce bug with release/14.10.31 as no inconsistencies occurred. Locally changed files are overwritten during the invitation process.
There should be inconsistencies in partial sharing mode because the meta file that contains the file enconding information for all files of the project is not shared per default.
Last edit: Stefan Rossbach 2015-01-05