Bug 159875 - [ltk] TextFileChange uses buggy org.eclipse.core.filebuffers APIs
Summary: [ltk] TextFileChange uses buggy org.eclipse.core.filebuffers APIs
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.1.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: needinfo
Depends on: 118199
Blocks:
  Show dependency tree
 
Reported: 2006-10-05 09:54 EDT by Ed Swartz CLA
Modified: 2009-08-30 02:08 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Swartz CLA 2006-10-05 09:54:19 EDT 
If a TextFileChange is invoked which changes a non-existent file, then an underlying bug in org.eclipse.core.filebuffers means a file will be created outside the workspace.  (See bug 118199, which incompletely describes the issue -- it's not just that java.io.File writes the file, but that the workspace-relative path is used as an absolute path.)

It looks like a workaround (in TextFileChange) could be either to throw a CoreException from #acquireDocument if a file doesn't exist yet (thus indicating that you shouldn't "change" a nonexistent file), or check for file non-existence and compensate for the bug by passing a resolved filesystem IPath to the IFileBufferManager APIs that take IPath.

I noticed that NLSPropertyFileModifier seems to avoid this with a custom CreateTextFileChange() when the target file does not exist.  Was that another workaround for this?
Comment 1 Ed Swartz CLA 2006-10-05 10:08:35 EDT 
BTW, there's a simpler workaround (though it's not undoable), along the lines of:

TextFileChange tfc = new TextFileChange(...) {
	protected IDocument acquireDocument(IProgressMonitor pm) throws CoreException {
		if (!getFile().exists()) {
			getFile().create(new ByteArrayInputStream(new byte[0]), false, pm);
		}
		return super.acquireDocument(pm);
	}
};
Comment 2 Martin Aeschlimann CLA 2006-10-06 12:20:37 EDT 
I don't think should implement workarounds, but wait for a better solution by the IFileBufferManager along the lines of bug 118199 comment 2
Comment 3 Denis Roy CLA 2009-08-30 02:08:15 EDT 
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.