Community
Participate
Working Groups
Build Identifier: 201010141000 The copyright rewriting tool fails silently on read-only files. Reproducible: Always Steps to Reproduce: 1. set a file to be read-only 2. right-click and choose 'Fix Copyrights' 3. note file was not changed and console log displays no reason
I believe this tool is "owned" by the Platform releng team.
I added a fix that checks if the file is read-only. I.e, if the file 'should' be updated, but is read-only, then it throws a warning containing the file name using the warn method. Gerrit review: https://git.eclipse.org/r/#/c/30622/ David, if you have time, would you be able to review it? Thank you,
I think your proposed fix is fine for the main problem, as stated, but I do wonder what the "real" use-case is? I ask because in Eclipse there is a "validateEdit" API, (on resources) that is meant to improve the work flow for those that use a "locking" version control system, such as Perforce, and others. The idea is that users "get" projects from the VCS, but can not edit them until they explicitly "checkout" the project (or, files?) Apparently some do use this model so that only one person can chance a file or project at a time (instead of having to working about "merging" later. That's the main reason for people to be trying to edit "read-only" files. This bug is pretty old, and not sure if originator (Paul Fife) is still around to care about this use-case ... but he'd be the one to say for sure if that is the use case he'd really like addressed ... or if a simple warning to log suffices. Frankly, I personally don't care. This is only an "informal tool" ... not an integrated part of the workbench ... so not sure it has to be as well behaved as the rest of the IDE (Editors, etc.). But, I feel in my role of "teaching" you, Leo, I would be remiss if I did not bring this up, and let you study it some (if you haven't already) and let you decide if you want to try the "deluxe" solution with these advanced Eclipse techniques ... or go with what you've provided? If you want to study/try it, besides reading about the validateEdit API, there is an example plugin, somewhere, called the "pessimistic file system provider" which "mimics" the behavior of these locking VCS's .... that is, you don't actually have to have Perforce installed or anything to see it working (and testing). So, let me know if you'd like to go one way or the other. And, again, I am not pushing for this deluxe solution -- I could live with either -- just wanted to be sure we were explicit about it, and understood the "real" use-case. Thanks,
Hmm, I see. Thank you for the detailed comment. @Paul If you do get around to reading this, as a solution, I could add a checkbox in the options 'warn on read-only files' that would be disabled by default but could be enabled for some special case. Thank you
(In reply to Leo Ufimtsev from comment #4) > Hmm, I see. Thank you for the detailed comment. > > @Paul > If you do get around to reading this, as a solution, I could add a checkbox > in the options 'warn on read-only files' that would be disabled by default > but could be enabled for some special case. > > Thank you The fix should use validateEdit with a headless context.
(In reply to Dani Megert from comment #5) > (In reply to Leo Ufimtsev from comment #4) > > Hmm, I see. Thank you for the detailed comment. > > > > @Paul > > If you do get around to reading this, as a solution, I could add a checkbox > > in the options 'warn on read-only files' that would be disabled by default > > but could be enabled for some special case. > > > > Thank you > The fix should use validateEdit with a headless context. Why headless? Isn't this always used from a live IDE? Or are there some "batch" use-cases I've not heard of? Oh, I think I see now (now that I've looked at code) ... that part of the code doesn't pre-req any UI components. (right?)
(In reply to David Williams from comment #6) > (In reply to Dani Megert from comment #5) > > (In reply to Leo Ufimtsev from comment #4) > > > Hmm, I see. Thank you for the detailed comment. > > > > > > @Paul > > > If you do get around to reading this, as a solution, I could add a checkbox > > > in the options 'warn on read-only files' that would be disabled by default > > > but could be enabled for some special case. > > > > > > Thank you > > The fix should use validateEdit with a headless context. > > Why headless? Isn't this always used from a live IDE? Or are there some > "batch" use-cases I've not heard of? Oh, I think I see now (now that I've > looked at code) ... that part of the code doesn't pre-req any UI > components. (right?) The main reason is, that I want to be able to run the copyright pass over night (due to the known performance issue). I'd be really frustrated when it stops in the middle just to wait for me to confirm a dialog.
(In reply to Dani Megert from comment #7) > (In reply to David Williams from comment #6) > > (In reply to Dani Megert from comment #5) > > > (In reply to Leo Ufimtsev from comment #4) > > > > Hmm, I see. Thank you for the detailed comment. > > > > > > > > @Paul > > > > If you do get around to reading this, as a solution, I could add a checkbox > > > > in the options 'warn on read-only files' that would be disabled by default > > > > but could be enabled for some special case. > > > > > > > > Thank you > > > The fix should use validateEdit with a headless context. > > > > Why headless? Isn't this always used from a live IDE? Or are there some > > "batch" use-cases I've not heard of? Oh, I think I see now (now that I've > > looked at code) ... that part of the code doesn't pre-req any UI > > components. (right?) > > The main reason is, that I want to be able to run the copyright pass over > night (due to the known performance issue). I'd be really frustrated when it > stops in the middle just to wait for me to confirm a dialog. I see what you mean. Ok, so if I understand correctly, for now we are waiting for Paul's use case is that correct? Otherwise I could start on a headless implementation, perhaps with a checkbox in the options?
(In reply to Leo Ufimtsev from comment #8) > (In reply to Dani Megert from comment #7) > > (In reply to David Williams from comment #6) > > > (In reply to Dani Megert from comment #5) > > > > (In reply to Leo Ufimtsev from comment #4) > > > > > Hmm, I see. Thank you for the detailed comment. > > > > > > > > > > @Paul > > > > > If you do get around to reading this, as a solution, I could add a checkbox > > > > > in the options 'warn on read-only files' that would be disabled by default > > > > > but could be enabled for some special case. > > > > > > > > > > Thank you > > > > The fix should use validateEdit with a headless context. > > > > > > Why headless? Isn't this always used from a live IDE? Or are there some > > > "batch" use-cases I've not heard of? Oh, I think I see now (now that I've > > > looked at code) ... that part of the code doesn't pre-req any UI > > > components. (right?) > > > > The main reason is, that I want to be able to run the copyright pass over > > night (due to the known performance issue). I'd be really frustrated when it > > stops in the middle just to wait for me to confirm a dialog. > > I see what you mean. > Ok, so if I understand correctly, for now we are waiting for Paul's use case > is that correct? Yes, we should just wait for the use-case and spend our time on more important bugs in the meantime.
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.
