Community
Participate
Working Groups
Scenario: 1, In a team environment, user1 launches a workspace and maps to a ClearCase stream 2, User1 imports the project with the auto-build on 3, One of the builder calls Eclipse IFILE.setCharset() API on newly generated files as a result of the build 4, Notice .settings/org.eclipse.core.resources.prefs file is silently checked out in user1's view 5, User2 launches a workspace and maps to the same stream as user1 6, User2 imports the project with the auto-build on 7, Build failed with no error 8, Notice in .log file, there are errors complaining about not able to check out .settings/org.eclipse.core.resources.prefs file Expected result: Eclipse IFILE.setCharset() API shouldn't check out files silently, whenever it needs to access a file, it should prompt for a check out dialog to get user's attention, or at least it should generate a build report with the detailed error messages inside in order for user to quickly fix the errors and rebuild again.
This is a known problem. There is an API called IFileModificationValidator that is used to notify a repository that an attempt is being made to modify a read-only file. When the validator receives an edit request, it checks the file out of the repository and makes it writable. If a Shell is passed along with the edit request, then the validator will prompt the user to confirm before doing so. The code that stores preferences such as the file's charset does not have any knowledge/dependency on any UI, so it can't provide a Shell to use as the parent for the prompt dialog. Thus there is no prompt and the checkout occurs silently. Can you provide the stack trace from the failure? It sounds like the builder could do a better job of surfacing the error.
(there is related discussion in bug 130266)
This is an easy fix for M7 now that we have the necessary validateEdit API.
Updating title, since charsets are just stored as project preferences. The silent checkout problem actually lies in the project preference code.
Fix released.
