Bugzilla – Full Text Bug Listing
| Summary: | [prefs] Preferences lost when moved between nodes | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Szymon Ptaszkiewicz <sptaszkiewicz> | ||||
| Component: | Compendium | Assignee: | equinox.compendium-inbox <equinox.compendium-inbox> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | daniel_megert, jamesblackburn+eclipse, john.arthorne, Mike_Wilson, Szymon.Brandys, tjwatson, yevshif | ||||
| Version: | 3.6.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | stalebug | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 207510 | ||||||
| Attachments: |
|
||||||
My understanding is that IPreferenceChangeListeners are called synchronously. So at a minimum an IPreferenceChangeListener that causes another PreferenceChangeEvent to be fired will insert that event in front of the original event which will cause out of order events for the remaining listeners. I am not sure if that is what is leading the issue here or not. (In reply to comment #1) > My understanding is that IPreferenceChangeListeners are called synchronously. > So at a minimum an IPreferenceChangeListener that causes another > PreferenceChangeEvent to be fired will insert that event in front of the > original event which will cause out of order events for the remaining > listeners. I am not sure if that is what is leading the issue here or not. This is not related to the problem (at least not directly). We are able to simulate losing preferences without listeners by overriding methods internalPut and remove. You can see that in patch attached to bug 332930. We should come up with a fix for 3.6.2. Otherwise the user may lose encodings, if he edits core.resources.perf manually. Ping! (In reply to comment #0) > The problem is connected partially to exported preferences and the > way how they are applied. When applying exported preferences, preferences are > moved to another node in listener and then they are applied again to the same > node from where they were removed. > Can you explain this statement a bit more? I'm looking at the code in PreferencesService#applyPreferences and it seems to apply changes in-place to the global node. Unless we are talking about the case where one of the preference changes are in sub-node in which case I believe we remove the global subnode and replace it with what was on disk. Also, what is the use-case in which this happens? I'm guessing it may occur if another team member modifies the project preference values in the repository in such a way that a sub-node is changed and you catch up to those changes while at the same time you modify them in the Preference Pages in the UI? I'm trying to determine the likelihood of this happening. Thanks. You can reproduce it without repository using 3.7 build and the following steps: 1. Create test project. 2. Create a text file. 3. Set custom encoding for this file (for example UTF-8). 4. Mark the file as derived. 5. Go to project properties and turn on 'Store the encoding of derived resources separately' option. You should get two files core.resources.prefs and core.resources.derived.prefs. 6. Now open core.resources.prefs in Eclipse text editor and change 'true' into 'false'. You should see that core.resources.derived.prefs is removed but the encoding setting for the file was not moved to core.resources.prefs. Encoding is not stored in any prefs file but it is still available so if you go to properties of the text file you will see UTF-8 there. If a user closes Eclipse at this moment, the encoding will be lost. Now, if you revert the value in text editor back to 'true', you will see that core.resources.derived.prefs appears again with correct encoding value. So.... not likely then? :-) This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag. This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag. |
Created attachment 184606 [details] Patch with tests showing the problem If preferences are moved between nodes inside org.eclipse.core.runtime.preferences.IEclipsePreferences.IPreferenceChangeListener.preferenceChange(PreferenceChangeEvent) then it is possible that those preferences will be lost. Attached tests show the problem. The problem is connected partially to exported preferences and the way how they are applied. When applying exported preferences, preferences are moved to another node in listener and then they are applied again to the same node from where they were removed. This happens because those moved preferences are still present in exported preferences that were created before the move operation occurred. Description of tests: there is a preferences 'somePreferenceName' that tells where preferences of 'someNode' node should be stored. If 'somePreferenceName' is false, then we want to keep preferences in 'org.eclipse.core.resources/someNode' node; if it is true, then to keep preferences in 'org.eclipse.core.resources.derived/someNode'. When running the tests you will see that tests tagged as 1.2.1, 2.2.1, 3.2.1 and 4.2.1 fail and result in inappropriate content of prefs file. Reproducible: Always