Bugzilla – Full Text Bug Listing
| Summary: | [regression] copy a text file -> should be added to context | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Lars Vogel <Lars.Vogel> | ||||||||
| Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | beyhan.veliev, Lars.Vogel, sam.davis, shawn.minto, steffen.pingel, wrobel | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | 3.7 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Lars Vogel
Lars, which release of Mylyn are you using? We recenctly made some changes to the resource monitoring and I am wondering if we are ignoring too many events now. Steffen, I'm using the Mylyn included in Eclipse 3.6.2 Helios. Thanks. That's the release where the resource monitoring changed. I'll tentatively schedule this for 3.4.3 so we remember to investigate. Sam, if you get a chance could you take a look at this? Sure. Shawn: This used to work. Could it be the change to our resource monitoring policy? Yes, this is most likely the cause of the problem but I have not had time to investigate it yet. Sorry, the target milestone got lost when moving bugs between projects. I would like to get this fixed for 3.5. Hi Lars, I can't seem to reproduce this based on the steps that you provided. The only time that I see items that are copied not being added to the context is when: # activate a task # go to the filesystem and find a file that has not been modified recently # make a copy of this file # refresh the folder in Eclipse This "failure" is due to the policy that we have where only files that were modified while the current task is active are added to the context. I need to investigate whether we can get the creation date of files as well so that we can improve the handling of this case. Hi Shawn, I have this behavior every day, so it difficult to see why it works for you. For example: 1.) Create General project "mylyn" 2.) Create new local task and activite it 3.) Create new folder 4.) Create new file in Eclipse 5.) Cntl+C and Cntrl+v the file in Eclipse -> not added to active task Best regards, Lars If I follow the exact same steps it works for me. Lars, can you try starting with a fresh workspace to verify that you can reproduce it with the default settings? To clarify, if Tasks > Resources > Enable file change monitoring is disabled in the preferences I can reproduce the problem described in comment#11 but that setting should be enabled by default. Also check if there are any exclusion rules that would disable resource monitoring on folder you are pasting into. Hi Steffen, In my normal workspace I have Tasks > Resources > Enable file change monitoring enabled and no exclusions are defined. If I create a new workspace it still shows the same behavior. The default creates a few exclusions **/.*/**, etc. But even if I delete them a newly copied file is not added to the context. Best regards, Lars Shawn, what is the status of this bug? I am moving this to the next milestone. We currently don't have a good handle how to investigate further. Lars, if you are at EclipseCon I suggest that we take a look at your workspace together. Thanks Steffen. Unfortunately I will not be able to join EclipseCon. Perhaps the next time we meet we find some time to look at this issue. :-) Steps to reproduce: 1. Activate a task 2. Copy an existing file that has a modification and creation date pre-dating the task activation 3. Paste the file The file is not added to the context. It turns out that I am able to reproduce this now! I don't know why I couldn't when I tried before. The problem is the date modification strategy is only able to take into account the modification date of the file (which does change when a file is copied). Also, we are unable to detect if this change happened in Eclipse or from the workspace. I wonder if we should just remove the use of this strategy for the case of added files and just allow the heuristic of the number of files being added control the context pollution. I will have a deeper look into this as well and see if there isn't something else that we can do. *** Bug 345695 has been marked as a duplicate of this bug. *** I am noticing this too, when copying a file within Eclipse. Timed out. Deferring to next maintenance release. I had another look into this and see no good solution here still. The proposed fix in comment #19 is still the only valid one that I can think of as copying a file does not update the modification date and therefore it will not be modified when active. Steffen, what do you think about disabling the modification date heuristic when it is a file addition? Let's do that. I don't see any simple way to detect user initiated file creation vs. tool initiated file creation and as long as we can control the volume of added files that seems like a good middle ground. Great to see that this bug might be closed in the near future! Thanks. Shawn, have you considered hooking into org.eclipse.ltk.core.refactoring.IUndoManager? I have pushed a small change here that seems to work but I am not sure if it has any undesired side effects: http://review.mylyn.org/#change,369. The integration tests passed. I'll put this change into the next build to include it in 3.7. Thanks for your patience, Lars! I just ran a test here on windows from and it seems to work for the main use case of copying a file between folders. There is one case where the file is still not added to the context when copying and that is when you copy a file and paste it into the same directory and need to give it a new name. I don't think that this is as frequent as a use case, so maybe we should just have a separate issue to track this limitation. Created attachment 212795 [details]
interest levels
That seems to work for me even though the interest levels are a bit odd and it's not decorated as interesting (even though it shows in focused mode).
@Shawn: Copying a file in the same folder with a new name is exactly my use case and why I opened this bug. See also the original bug description in which I don't switch folders. Hence if that still doesn't work it should be continued to be tracked via this bug. Lars, can you verify if the latest weekly build works for you? It is available from http://eclipse.org/mylyn/downloads/#weekly . @Steffen: Will do, currently at the airport with less then optimal working conditions. ;-) Created attachment 212799 [details]
fix for resource events
Created attachment 212800 [details]
mylyn/context/zip
After looking into this further with Shawn we decided to try a slightly different approach using a an IOperationHistoryListener: http://review.mylyn.org/374. I'll kick off a new weekly build. Looks good to me. Thanks for the fix, this was a very annoying bug for me. |