| Summary: | [server] user.json corrupted by an invalid recentSearch property | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Anthony Hunter <ahunter.eclipse> |
| Component: | Server | Assignee: | Anthony Hunter <ahunter.eclipse> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | gheorghe, mamacdon |
| Version: | unspecified | ||
| Target Milestone: | 8.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
IIRC the 'window/favourites/recentSearch' pref has not been used since the Saved Search feature was removed from the UI several months ago. Nobody in the client code is getting or setting that pref anymore, so I'm not sure how it could've gotten corrupted. Bogdan had a similar issue in the window/favorites/recentFind property that I fixed just now. (In reply to Anthony Hunter from comment #2) > Bogdan had a similar issue in the window/favorites/recentFind property that > I fixed just now. Long shot, but.. If you press Ctrl+F while text is selected in the editor, the selected text gets saved into the recentFind pref. It doesn't seem to enforce a size limit. So if you Select All and hit Ctrl+F in a large file, it will fill up your pref with garbage. It still doesn't explain 1MB of \\u0083Ã though, unless Ken (and Bogdan) were both viewing a bunch of binary gibberish and happened to use the Find command. We should either (or both): a) put some guards around this so users don't accidentally shoot themselves in the foot or b) refactor user.json and put the volatile type of things (the task job stuff) that can grow into another file This problem has not reoccurred, marking resolved. |
Ken could not use the sites feature on orion.eclipse.org. When I copied his server metadata files to my machine, I could not even login as the /workspace call was timing out taking longer that 15 seconds. The issue is caused by a corrupt recentSearch property in his user.json. It is 1,106,695 characters long It starts fine with: "window/favorites/recentSearch": "[{\"name\":\"clipboard\",\"regEx\":false},{\"name\":\" Ã\\u0083Â\\u0083à And then it has I guess over a million à and \\u0083 characters. I am not sure what this character is or who put it there. I doubt Ken entered a million characters into a search query. The problem is resolved once I remove this property manually.