Bugzilla – Full Text Bug Listing
| Summary: | FileDocumentProvider is not EFS compatible | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Knut Wannheden <knut.wannheden> |
| Component: | Text | Assignee: | Platform-Text-Inbox <platform-text-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, remy.suen |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
This class has never been updated for EFS and there are no plans to do so. The much more powerful TextFileDocumentProvider should be used which is able to handle EFS. Hi Dani, Thanks for the clarification. I've added a corresponding ticket to Xtext (bug 326961) where we currently still use the FileDocumentProvider. |
We have a problem with an editor implemented using FileDocumentProvider. The document's input is a file loaded from an EFS store and when trying to save the resource the document provider comes to the conclusion that the resource does not exist. This decision is based on the result of the method isDeleted(): public boolean isDeleted(Object element) { if (element instanceof IFileEditorInput) { IFileEditorInput input= (IFileEditorInput) element; IPath path= input.getFile().getLocation(); if (path == null) return true; // <<<----- return !path.toFile().exists(); } return super.isDeleted(element); } Our EFS-stored resource returns null for getLocation(). The workaround is to let the resource decide whether it exists: IPath path= input.getFile().getLocation(); if (path == null) return !input.getFile().exists(); Shouldn't also always the getLocationURI() method be used in Eclipse projects? See http://wiki.eclipse.org/EFS_for_Platform_Committers.