Community
Participate
Working Groups
Build Identifier: All The warning message "Resource is out of sync with the filesystem" is incredibly unhelpful. Apparently this feature exists so that the files that have been accidentally deleted can be recovered. I believe that this is little more than an annoyance, hindering people that work using tools that are not integrated with the eclipse platform. My suspicion is confirmed by the fact that the warning message provides no instruction on recovering the cached version (which would be the only function of this) instead just telling you to go refresh the resource - something that would be easy to do automatically. Eclipse should make it easy to work. This message achieves nothing except blocking access to a file which is obviously of interest. Any problem with a file that has been altered accidentally could be recovered using the local history - even if it has been deleted. I am filing this as a bug because it is a feature with negative value. Removing this behaviour would improve Eclipse. Reproducible: Always Steps to Reproduce: 1. Create a project with at least one file in it 2. Open the file in eclipse, edit it, save it, and close it 3. Open the file using a text editor not integrated with eclipse, edit it, save it, and close it 4. Open the file in eclipse At this point the warning message will be shown 5. Close the file, refresh the project 6. Delete the file without using eclipse 7. Refresh the project, notice that the file is removed 8. Right click the root of the project and select 'Restore from local history...' 9. Select the checkbox by the file in the top left hand pane, and select the most recent edit in the local history (top right hand pane), and then click the Restore button This will restore the file
I know we've had bugs on this closed INVALID / WON'T FIX before. However I'd like to take a stab at making this a tad better for non Windows users. On discovery the resource is out of sync, we could queue the resource for refresh with the refresh manager, which would ensure it comes back into sync asap. Can anyone think of a reason not to do this?
Because it would send deltas and trigger all listeners, what basically could make this operation way longer?
BTW, there is an option to refresh your workspace automatically and keep it in sync with fs, if it is really required.
(In reply to comment #2) > Because it would send deltas and trigger all listeners, what basically could > make this operation way longer? The RefreshManager actions happen asynchronously (this is the same mechanism as used by the file system update hooks). I'm not suggesting we update the sync state immediately, as this isn't possible when the workspace / resource tree is locked (checking sync state doesn't require locking the resource, but updating it does). I'm simply suggesting adding the resource to the refreshmanager's refresh list. The performance impact for doing this should be minimal. That aside, the only way to recover from this is for the user to either manually intervene and perform the refresh, or for a refresh to happen automatically due to a fs hook and the refresh manager. Overall the amount of work done should be the same.
(In reply to comment #3) > BTW, there is an option to refresh your workspace automatically and keep it in > sync with fs, if it is really required. Right, but on non-Windows platforms that involves polling all directories in the filesystem. On Windows this uses the FS hook. On some non-local filesystems, polling is extremely heavyweight. The "Refresh Automatically" feature is orthogonal to this. This would simply update the sync state, at the next possible opportunity, for IResources the workspace already knows are out of sync.
I have tried using the option, but it does not trigger a refresh of a file immediately if I open it. It appears to just periodically refresh all files. Triggering a refresh when you open the file would be great. There is one additional point that may get missed if the refresh occurs in a similar way to a manual refresh: losing the point in the file which is of interest. This is easily explained with an example: 1. Create a project with two Java files, one which has a method in, and the other which contains a call to that method. The method containing file should be large enough that the method requires scrolling to reach. 2. Alter the method containing file outside of eclipse. 3. Open the call containing file and right click the call and select 'Open Declaration' (or use the shortcut). 4. The "Resource is out of sync with the filesystem" warning will be displayed. 5. Refresh the file. At this point the file will be displayed, but it will display it starting at the top - not starting at the method that was
Erp - clicked too soon. Meant to finish with 'not starting at the method that was of interest'
(In reply to comment #4) Improving RefreshManager is a separate issue and you should perhaps raise a bug for it. This bug though, as you already said, is a duplicate of one of closed INVALID / WON'T FIX bugs. Bug 14867 or similar.
(In reply to comment #8) > (In reply to comment #4) > Improving RefreshManager is a separate issue and you should perhaps raise a bug > for it. Ok, I don't really mind where the bug is filed :). It's not quite all refresh manager -- from my POV the resource plugin should notify RM when it hits an out of sync resource.
(In reply to comment #9) James, it looks like you have a patch ready already, right? ;)
(In reply to comment #10) > (In reply to comment #9) > James, it looks like you have a patch ready already, right? ;) Heh not yet ;). Just a bug lodged in our local bug database.
The general reason for this behavior is to avoid the user accidentally changing something they are not aware of. For example, consider a folder with two files, a.txt and b.txt. a.txt was created in eclipse, so it is visible in the project explorer. b.txt was created directly in the file system so it is not currently known to eclipse. Now the user decides they no longer need a.txt, and since it appears to be the only file in the folder, they select the folder in Eclipse and hit Delete. If this automatically deleted b.txt, which they weren't even aware of, it could result in unrecoverable data loss for the user. Since b.txt was never discovered by eclipse, it will *not* be in the local history. This is just one example, but similar use cases can be constructed for operations other than deletion, which involve data loss for the end user due to changing files/folders they are not aware of. Having said that, I agree there are workflows in the UI that could be made easier here. For example when reporting something is out of sync, they could offer to "refresh and retry" with a single button click rather than forcing the user to go through a more elaborate set of steps.
If eclipse refreshed the folder before performing the delete as requested, wouldn't that add b.txt to the local history?
Created attachment 159815 [details] One-click button to refresh (In reply to comment #12) > Having said that, I agree there are workflows in the UI that could be made > easier here. For example when reporting something is out of sync, they could > offer to "refresh and retry" with a single button click rather than forcing the > user to go through a more elaborate set of steps. We do this already for text editors in Eclipse SDK.
(In reply to comment #14) > We do this already for text editors in Eclipse SDK. It looks like you're on Windows with auto-refresh on? Isn't that dialog notifying you that a post-change event has happened as a result of a refresh from the windows hook? It doesn't do this for me on Linux...
(In reply to comment #15) > It looks like you're on Windows with auto-refresh on? I take that back: it seems to work in my 3.6 workspace but not n 3.5...
*** This bug has been marked as a duplicate of bug 303517 ***
