I tested your latest code and everything looks fine now. I then changed the isReadOnly method to use IFile API instead of java.io.File. It also works so I think calling iFile.isReadOnly would be the way to go.
The test included a read only unmanged file, a read only managed file, a writable managed and a writable unmanaged file. I was prompted to lock the managed read only file and I got the prompt to switch the read only flag on the read only unmanaged file. No prompts appeared for the writable files.
I noticed one more thing which is probably something that affects several classes: When I decide not to lock a read-only file I get an error message with an empty reason string. This is because the Status.CANCEL is returned which does not have and description (it should according to the javadoc in IFileModificationValidator). The same would be the case if the LockResourceCommand would fail.
I appreciate the effort you put into this. Thank you very much!
From: Mark Phippard [mailto:email@example.com]
Sent: Tue 12.12.2006 02:36
Subject: Re: Re: RE: [Subclipse-dev] Bug introduced with 1.1.9 - LockDialog
On 12/11/06, Thomas M. Hofmann <firstname.lastname@example.org> wrote:
Please try the attached patch. I still think the validator for the files not managed should only get the ones passed that are not managed.
The patch is not based on your latest submission since I did not read your mail before I tried to change it myself.
Please try again with latest. I did a major refactoring to split the files into managed and unmanaged so that they can be processed just once and separately. This should address your concerns. I am still using my java.io.File based method of determining if the files are read-only. I think the current code works correctly though. It is possible that is not necessary, but it does not really hurt anything.
Received on Tue Dec 12 16:46:20 2006
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org