Encoding, unmappable characters: Local "Save" is not applied remotely

[dpp-gerrit]

Scenario with Alice and Bob. Alice's project and its files has the encoding "US-ASCII".

• Alice starts the session with Bob.
• Alice enters umlauts (a, ö, ü) into version of the file. These changes will be propagated and applied on Bob's side.
• Alice saves her file. Eclipse opens an error message, informing her that some characters cannot be mapped onto "US-ASCII", and offers her the possibility to save the document as "UTF-8".
• Alice saves the document using "UTF-8". The "dirty" marker (asterisk next to the filename) disappears.
• However, on Bob's side the "Save" action won't be applied, although his Eclipse should know by now that the file's encoding has been changed from "US-ASCII" to "UTF-8".

The only difference between Alice's and Bob's state is the "dirty" marker. Both are able to continue working. Subsequent saving operations from Alice still show now effect. Bob has to save the file himself, and tell his Eclipse that this file should now be regarded as "UTF-8" (using the same dialog that popped up on Alice's side before).

For further information see the attached logfiles (Alice == zieris_test01, Bob == zieris_test02).

Alice.log
Bob.log

Reported by: fzieris

Original Ticket: dpp/bugs/822

[dpp-gerrit]

Well just look at Bobs log file.

ERROR 2013-12-10 18:44:44,398 (EditorManager.java:1486) Failed to save document: SPath [editorType=txt, path=src/MyClass.java, project=EncodingTest]
org.eclipse.core.runtime.CoreException: Some characters cannot be mapped using "US-ASCII" character encoding. Either change the encoding or remove the characters which are not supported by the "US-ASCII" character encoding.
	at org.eclipse.core.internal.filebuffers.ResourceTextFileBuffer.commitFileBufferContent(ResourceTextFileBuffer.java:373)

Although the "encoding" file is transmitted first Eclipse do not realize this, see Alice

DEBUG 2013-12-10 18:44:44,335 (ProjectDeltaVisitor.java:262) Resource org.eclipse.core.resources.prefs changed
DEBUG 2013-12-10 18:44:44,351 (ActivitySequencer.java:529) send (001) [[email protected]/Saros] [FileActivityDO(type: CREATED, path: SPathDataObject [editorType=txt, path=.settings/org.eclipse.core.resources.prefs, projectID=1522881358])]
DEBUG 2013-12-10 18:44:44,352 (DirtyStateListener.java:67) Dirty state reset for: L/EncodingTest/src/MyClass.java
DEBUG 2013-12-10 18:44:44,352 (ActivitySequencer.java:529) send (001) [[email protected]/Saros] [EditorActivityDO(type: SAVED, path: SPathDataObject [editorType=txt, path=src/MyClass.java, projectID=1522881358])]

Original comment by: kargor

[dpp-gerrit]

So where do you see the failure: Alice's, or Bob's side? Saros or Eclipse?

Original comment by: fzieris

[dpp-gerrit]

Well, regarding the fact that I did not like the transmission of meta data I do not know if there is really anything we can do about that. We use the document provider to save the data. See EditorManager line 1486. I think Eclipse is doing the same but just catching the Exception and asking the user. This is the part we do not do and just "ignoring" it.

Original comment by: kargor

[dpp-gerrit]

So do it understand it right: Bob currently has no chance of knowing that Alice changed the encoding?
Because if he did know, I wondered why his Eclipse does not recognize it.

Original comment by: fzieris

[dpp-gerrit]

The encoding change is currently only send by transmitting the metadata file (this is what I do not like). If I remember correctly the SWTP had worked on transmitting encoding changes (which is easily possible with the eclipse file API). Neverless I do not if this does offer us any advantage ... as it seems Eclipse is ignoring this change already (meta file is "correctly" overwritten) before we save the document. Maybe dig down through Eclipse source code to find out how the normal save operation handle it ? :P

Original comment by: kargor