Community
Participate
Working Groups
20031009 When ever you invoke an accelerator in the java editor the disk is accessed. STEPS 1) Create a project with a java file on your floppy 2) Open the file 3) Select format (Ctrl+SHift+F) 4) You will hear a disk access
i'm guessing this is an issue with the JDT actions themselves. tod, can you confirm that this happens *only* using the keyboard to invoke these actions and not by choosing the actions off of the menu?
Just popping up the menu without selecting anything does this. However the disk access only seems to happen when the file is dirty
------------------------------------------------------------------------------- | Task | Goes to Disk? | ----------------------------------------|-------------------------------------- | Selecting the file in the navigator | NO | | Opening the file from the navigator | YES | | Changing focus to the java editor | YES | | Right-clicking within the editor | NO | | Right-clicking within the navigator | NO | | Navigating the menus | NO | | Formatting the source (key or menu) | YES | ------------------------------------------------------------------------------- From this, I'm thinking it's either a problem with the text editor or with the source editor. I'll punt it to text....
Tod, can you be a bit more specifc. Reading the table in comment 3 the following two actions have to read the disk: - Opening the file from the navigator obvious - Changing focus to the java editor file must be reconciled since it might have changed So, is it correct that only the formatting actions seems to incorrectly access the disk? Which menu (main or context)?
Creating a project and then a class on the floppy went to disk with the following actions 1) Hitting return in a text editor 2) Formatting using Ctrl+Shift+F 3) Popping up the context menu
1) only the first time, right? (needs to check file state, e.g. read-only) 2) and 3) need to be investigated
could preferences lookup play a role here?
Only the first time or after saving yes.
could well be: format action reads the formatting profile
Also using code assistance (i.e. pressing ctrl-space) triggers editor to start doing at least 1 i/o on edited file during : 1. text selection. per each char/line selected at least 1 i/o access to edited file 2. text editing(next-word, previous-word, etc) 3. other editing commands(incremental find, etc...) this makes editing text on smb mounted partitions quite painful. On windows this i/o can easily be tracked on windows by using filemon(sysinternals.com).
needs to be investigated for final 3.0
I just tried to figure out what's going on and it seems for every modification event in text editor eclipse checks whether file is modifiable. For a single character selection TextEditor calls canModifyEditor() several times(probably different events) Here's related stack trace : Thread [main] (Suspended (breakpoint at line 179 in java.io.File)) java.io.File.<init>(java.lang.String) line: 179 org.eclipse.core.runtime.Path.toFile() line: 762 org.eclipse.core.filebuffers.FileBuffers.getSystemFileAtLocation (org.eclipse.core.runtime.IPath) line: 103 org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider (org.eclipse.ui.editors.text.TextFileDocumentProvider).getSystemFile (org.eclipse.ui.editors.text.TextFileDocumentProvider$FileInfo) line: 983 org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider (org.eclipse.ui.editors.text.TextFileDocumentProvider).isSystemFileReadOnly (org.eclipse.ui.editors.text.TextFileDocumentProvider$FileInfo) line: 987 org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitDocumentProvider (org.eclipse.ui.editors.text.TextFileDocumentProvider).isModifiable (java.lang.Object) line: 807 org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor (org.eclipse.ui.texteditor.AbstractTextEditor).isEditorInputModifiable() line: 4538 org.eclipse.ui.texteditor.TextOperationAction (org.eclipse.ui.texteditor.TextEditorAction).canModifyEditor() line: 109 org.eclipse.ui.texteditor.TextOperationAction.update() line: 136 Not sure what would be the proper fix for this but i'd check buffer last modification time and writablility once when user switches to buffer and keep that information cached.
Created attachment 10246 [details] diff for TextFileDocumentProvider.diff Not sure this is correct fix but it seems working well(still testing). Instead of calling isSystemFileReadOnly it returns FileInfo fCachedReadOnlyState that i suppose initialized in createFileInfo.
Note: the read-only state can change, either via Eclipse or outside.
Sorry for late response. Glad you asked about refreshing. In case when buffers are not automatically generated code but rather normal files opened by user eclipse nicely detect read-only/writable when user switches between buffers(ie this is refreshed when editor gets focus). If file permissions are changed when user edits the file and tries to save it eclipse shows nice warning saying file is read-only and marks it as r/o. So i do not see any regression in this case. As for editors containing dynamically generated code(do not know if this possible but assume it is) this property should be handled by applications/plugins.
Removing target milestone, no further action for 3.0.
As discussed with Kai this one can be considered a regression. The regression is really painfull when the file comes from a remote file system. Fix this problem should also be released into 3.0.1
Alexander's analysis is correct. I did not use his patch. We now call isReadOnly(element) instead of isSystemFileReadOnly(info).
Fixed in R3_0_maintenance branch. Released into I200409080800.
We forgot to release the change into the map file. Will be in next M-build.
Verified in M-M20040908-200409081421
*** Bug 76945 has been marked as a duplicate of this bug. ***
