There is one more caveat about resources manipulation in Eclipse's workspace. Scheduling a job with a resource scheduling rule helps to avoid unwanted intersections between different tasks. Say one job wants to modify some resource but other wants ro read some consistent state or modify same resoruce. This has two problems. First, there is no robust way to ensure jobs order, and second there is chance of lockups when using jobs for resource manipulation.
It turned out that this does not play well if your job is scheduled as part of bigger transaction. Say, Eclipse started some rename refactoring, your hob invoked as part of "save resources" procedure and wants to modify things so resources are consistent with saved editor state. And then you get into deadlock. Refactoring locked your resource for modifications, your job want to lock it for modifications too and there's no way to tell that your job is "nested" transaction. Oops.
Scheduling one job after other is tricky too. Even Eclipse's code waits for build completion before launch by polling job manager to ensure that there are no active jobs that tagged as "build job".
I found that in most cases (if your requirements are simple) better approach to modifying resources in Eclipse's workspace is to consistently use IResource's (IFile, IFolder, IProject) methods throughout your code instead of using plain java.io package. This would ensure that Eclipse is aware of your changes and you do not need to refresh resources after every modification to make Eclipse aware of it.
