Community
Participate
Working Groups
The validateEdit spec is unclear whether given a UI context that the receiver *must* prompt to inform the user of the reason why the file can't be modified. "By passing a UI context, the caller indicates that the VCM component may * contact the user DefaultFileModificationValidator should probably prompt to inform the user that the file isn't writeable. However, this point is being discussed in bug #28216.
Just ran into a problem where a validatEdit was performed by an operation that had a progress monitor. The CVS validateEdit also opened a progress monitor and this caused deadlock. Since it seems reasonable that a provider may want to perform a long running operation to check out a reosurce that an IProgressMonitor should be provided to validateSave and validateEdit (see bug 28646)
What about unmanaged/unshared read-only files in a project that is connected to a repository provider. Is it the responsibility of the repository provider to prompt for these files as well? It seems it would be given the above discussion. I'm not sure that this is a reasonable expectation (i.e. as a repository provider implementor, I'd rather not concern myself with unshared or ignored files at all).
Its a subset of the same problem: (for various reasons) the caller can't assume that the provider prompted just because it gave it a UI context. Ideally the provider would only prompt for files under its control. However, there would need to be a way to inform the caller which files were taken care of and which weren't since the argument could contain a mix. That's a bit more complicated, and its easier to just handle all or nothing.
The default provider will be changed to prompt. This will be accomplished by moving the code to org.eclipse.team.ui, which is ok since we assume nobody builds an eclipse without both team.core and team.ui. The prompt method could be made public API for Michael's case in comment #2. They would still need to detect the case, but then could rely on team.ui to prompt. They would have to fold back the stati.
*** Bug 33128 has been marked as a duplicate of this bug. ***
It's bad that this has been pushed back to 2.2. If I copy a file and the file exists in the destination and is read-only UI prompts to overwrite the read- only file and the copy fails silently when I select "yes". The user will not be aware that the copy in fact did not happen. This should be fixed ASAP in 2.2
Will there also be a prompt for files in projects that are not connected to a repository?
Post 3.0
I just hit this problem as well. I copied a bunch of files from a controlled project to an uncontrolled one. The read-only bit on all the resources was set. Editing fails silently. I had to manually unset the read-only bit on each file individually.
Fix released to HEAD. The use is now prompted when read-only files are modified in unshared projects.
*** Bug 75872 has been marked as a duplicate of this bug. ***
*** Bug 75854 has been marked as a duplicate of this bug. ***
*** Bug 73381 has been marked as a duplicate of this bug. ***
