tree 8f029c1a5d975c29cf2339d2b774b98c8bc3259b
parent 429cd04f6f8b5eca3200d3119d6ac30da41e5271
author Andrey Loskutov <loskutov@gmx.de> 1574265521 +0100
committer Andrey Loskutov <loskutov@gmx.de> 1574265521 +0100

Bug 553269 - Eclipse detects changed ENCODING on opening a project with
explicit encoding set

After closing and opening a project we do not expect ENCODING flag to be
in the resource delta send, but the code does exactly that *if* the
project encoding was modified at least once during the current Eclipse
session. This problem was introduced in bug 84350.

ResourceInfo.incrementCharsetGenerationCount() writes two parts of an
int into charsetAndContentId (and
ResourceInfo.getCharsetGenerationCount() uses the upper part), but
ResourceInfo.writeTo(DataOutput) and ResourceInfo.readFrom(int,
DataInput) read/write only the lower part.

So every time Container.setDefaultCharset(String, IProgressMonitor) is
called (for example after reading
.settings/org.eclipse.core.resources.prefs with encoding set), the
"current" (in memory) project info differs from saved/loaded project
info.

Since the "current" project info remains in memory after closing the
project, its charsetAndContentId content will be always different
compared to the data read back from disk.

After Eclipse restart, where *all* the data is loaded from disk,
charsetAndContentId will be consistent (it will not have
"CharsetGenerationCount" part anymore), and the troubles start again
only after someone touches .settings/org.eclipse.core.resources.prefs in
some way (either by changing encoding settings via UI or via git/other
direct resource operations).

Safest way to fix that would be NOT to change the way how the tree is
saved to disk (so do NOT save "CharsetGenerationCount" part of
ResourceInfo.charsetAndContentId), but instead, clean up this part on
closing the project in Project.internalClose(IProgressMonitor), similar
what is done via ResourceInfo.clearModificationStamp().

Change-Id: I77cd8c0af2e3283191e185a8683162b77e544f39
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>