How does a dirty EditorPart prohibit Eclipse from renaming its resource?

Say I have defined my own TextEditorX extends TextEditor. In the typical Eclipse-RCP scenario (standard plugins, workbench with Project Explorer/ Navigator) the behaviour when someone tries to rename (via Project Explorer or Navigator) a file that some editor has opened is:

• If the editor is not dirty, the renaming is allowed. Afterwards editor.setInput() will be called, with the new filename as argument.

• If it's dirty, an error is thrown ("Rename resource" : "A fatal error occurred while performing the refactoring" "Found problems: doc.txt is unsaved").

My questions:

• At which level is this behaviour defined? I guess that the package org.eclipse.ltk.ui.refactoring.resource is involved... But, suppose for example that I want to disallow the rename even when the editor is not dirty: could this behaviour be determined by some method in the editor (or the document provider), or should I code/extend some RenameParticipant ?

• How does the renamer knows that the resource doc.txt is opened by that editor instance? Does it just check all opened editors and ask each one for its editorInput, or are documentProviders involved? Specifically, suppose I have a particular editor that, besides the "main" file, depends on other resources (a multi-file input), and it want the renamer to ask him before renaming any of his inputs. How would you approach this scenario?

There's no theoretical reason for Eclipse to prevent a rename of a modified file. For one, the editor could register a ResourceChangeListener with the workspace, and simply update its IEditorInput in response to a MOVE notification. Not sure if that is a good answer but maybe a good approach to go.