Release installations of CodingTracker record spurious 'New File' operations

[Wanderer777]

CodingTracker installed as a release (as opposite to run from the source code) records spurious "New File" operations, where they should not be. For example, when a resource is moved and then edited, there is a "New File" operation in between, which should not be there. This problem can not be reproduced if CodingTracker is started from its source code.

[reprogrammer]

How serious is this problem? Can the spurious operations be removed during a post processing step?

[Wanderer777]

This problem happens because Eclipse uses different aliases for the same encoding during different scenarios. On my Windows machine these are windows-1252 and Cp1252, which are the same encoding. CodingTracker should compare encodings rather than strings that represent them to make sure that aliases are considered equal.

[reprogrammer]

@Wanderer777: Why didn't this problem show up when you tested CodingTracker in plug-in development mode?

[reprogrammer]

@Wanderer777: Could you list this issue in issue #274?

[Wanderer777]

@reprogrammer:

• Spurious 'New File' operations recorded by the older CodingSpectator releases (if any) would need to be filtered out as a post-processing step. But this is fine since some kind of filtering out of redundant 'New File' operations was planned since the beginning, because sometimes these operations are recorded just to ensure a robust behavior of CodingTracker, e.g. any known file becomes unknown after a week of not being changed. So, if a 'New File' operation discovers that its content is equal to the current content of the file during replay, then it will not be replayed.
• I did not discover this problem in the plugin development mode, because I used UTF-8 in that mode to be able to replay the collected data. And Eclipse did not use any aliases for UTF-8. But installing a released CodingSpectator in a fresh Eclipse, I did not change the default encoding, which is Cp1252. And Eclipse in some scenarios refers to this encoding as windows-1252, which caused the above problem. Therefore, I doubt that you could reproduce this problem even in the release mode on your Linux machine, since you are using UTF-8 by default.