:::: MENU ::::

FlashBuilder 4.6 Broken Workspace FIX

I’ve been running into a plaguing issue lately with FlashBuilder 4.6, and that is that every few days/weeks/other random increment of time, my workspace will become corrupt, and I will no longer be able to open it. The signifier (for me) of a corrupt workspace is generally that FlashBuilder freezes while I am in the middle of coding some (usually extremely important and time-sensitive update), then when I try to restart the application it hangs on the “Loading Workbench” portion of the startup sequence. Thankfully, I found THIS post written by Valentin Romonov which outlines a fix for the problem that doesn’t involve deleting the entire .metadata folder of the workspace (which then forces you to reset up all preferences, ties to version control systems, layouts, etc.).

The fix is quite simple: go into your project directory, and locate a file called .snap which is listed under the following path on Mac OSX: .metadata/.plugins/org.eclipse.core.resources Once you have deleted this file, simply restart FlashBuilder and you should be good to go! *Note that you will need to turn on hidden files in order to see the .metadata folder, instructions on how to do that can be found HERE.

A big thanks to Valentin Romonov for blogging about this fix, it has saved me a LOT of time and frustration!


  • Reply Emile |


    Do you keep Flash Builder open when you do updates from your source control repo?

    I have a fair amount of experience with a number of different IDEs, across programming languages and OSes, and have found that most of them do not handle project/workspace/solution related file changes very well and in most cases the IDE will crash. Sometimes immediately and sometimes after a delay of a few minutes.

    In Flash Builder’s case I’ve found that it handles source file changes ok, but when a project or other file that affects the workspace changes, while it is running, there seems to be some timing related (small) chance that the workspace will be broken in various ways. Different changes cause different issues and when you add to that the timing factor it all seems a little random – but I don’t think it is.

    From what I’ve experienced and comments I’ve read, I am fairly certain that many Flash Builder users use version control plugins to push/pull updates from the version control system while Flash Builder is open. Fine if you will only receive code changes, but not a good idea if you also receive project/workspace related file changes.

    It would be interesting if you could confirm whether you are pulling changes with Flash Builder open. If so, perhaps you should try closing FB before manually pulling updates, by using the command line or something like TortoiseSVN, TortoiseHg, etc. If you don’t experience any further issues with your workspace, then it would pretty much confirm my suspicion.

    Take care.

    • Reply Kyle |

      Hey Emile,
      I am fairly certain that you are correct in that source control software may indeed play a role in the cause of these corruptions. I was seeing this issue previously (though not as often) when using the Subversion SVN plugin for FlashBuilder. Recently, I had to install the Team Foundation Server plugin, and since then, this issue has run rampant. That being said, all of my version control is handled from within FlashBuilder using these plugins (I don’t do any other outside updates to the files).

So, what do you think ?