Joeflash’s Enigmacopaedia

Moving a Flex Builder/Eclipse Workspace Without Importing Anything (Update)

Posted in Flex, Workflow, Flex 3, Flex Builder 3, Eclipse by Joeflash on the November 27th, 2008

In the last post, I examined how to move a Flex Builder/Eclipse workspace to a different directory location without re-importing all your projects. Only it didn’t work as well as expected. I finally figured it out, but use at your own risk, since this involves editing Eclipse binary metadata files.

Currently there is no user-friendly technique for moving an entire Eclipse workspace folder to a different directory. This I most wanted to do because the current technique involves the painstaking task of creating a new workspace, then reimporting all projects, reconfiguring all compiler settings, and then re-imputing all the SVN location data for Subclipse. Blech!!

I wanted to move all my workspaces from my C:\ drive to a C:\_fx3\ directory to get them off the root drive. But I don’t have whole days to mess around with importing projects and making sure all the settings have been imported faithfully. I just wanted to move entire workspace folders to the new directory, make a few metadata file hacks, and be done with it.

Well, as it turns out, it’s not that easy. What makes all the difference for most workspaces are not the XML metadata, which seems to be mostly for caching, but the .location files in the metadata project directories, which is where the absolute directory location for each project folder is referenced. Problem is they’re not meant to be user-edited. So use this technique at your own risk, as other absolute directory dependencies may exist that I’m not aware of. For now consider this an experiment in progress.

1. Copy your workspace to the new directory location.

2. Edit the XML metadata files in the workspace folder as detailed in this last post.

Now here’s where it gets interesting.

3. Find the .location files in the workspace metadata. They are located in the

\{workspace dir}\.metadata\.plugins\org.eclipse.core.resources\.projects\{project folder}


3. Open up each .location file in a Hex Editor application. I’m using the free Hex Workshop utility from pbsoft.

Now let’s take a look at the process for editing one of those files.

4. Edit the URI in the binary data. In the Hex for each file you will see the characters “URI” followed by the absolute directory path for the project folder in question. Edit the path, making sure to add or delete bytes as required.

In my .location file, the old path is:


editing the .location file - start

I edit the new path to be


5. Edit the byte before the “URI” to be the new character length of the path.

If your code editor has hex-to-dec conversion, as mine does, you can see that the character length of my old path, which includes “URI”, is hex 2C or 44 characters (see image above).

Select that byte value, and replace it with the character length of the new path. I got the character length by using word count in MS Word (Tools > Word Count…).

URI word count

The length is 49 characters, which is hex 31.

editing the .location file

5. Save the file.

6. Repeat for each .location file.

Now when load up Flex Builder and point to the new workspace location, I verify that the project does indeed point to where I told it to in the .location file. And my SVN locations are conserved, as are all my preferences. YAY!! :)

verifying the successful workspace move

Unfortunately, although this hack works, it’s a lot more trouble (or at the very least the same) as making a whole new workspace and importing each project one by one. I had to Hex edit over 20 files to move the entire workspace — which could hardly be considered a time-effective solution. I can make things easier on myself my copying the entire workspace to my new directory, but I still have to delete and recreate the workspace metadata by pointing to that new workspace folder, and then re-import every project in that workspace. Still, I learned quite a few things about Eclipse in the process, which was partly the goal of the exercise for me anyways.

Although I’ve used it for a few days now and I have not seen any compile or file referencing problems, and it seems like a sound solution, this technique has not been battle-tested, and I’m not an Eclipse developer by any stretch, so I’ll say it again:
use this technique at your own risk. Don’t come crying to me if this hack corrupts or messes up your Flex Builder or Eclipse workspace in any way.

If indeed this hack proves to be stable, as it seems to be, the next step would be to create a batch file or something that could at once copy the complete workspace directory to a new location, seek out and edit all the required XML metadata files with the correct path references, and hex edit all the .location files with the changed URI and adjust the length byte accordingly. Maybe even a custom eclipse plugin written in Java? Hmmm… But that task lies beyond my time and current programming abilities at present, so I will leave you with that final tantalizing thought.

(maybe some enterprising Eclipse developer will read this and decide to surprise us with a plugin, hint hint ;) )

7 Responses to 'Moving a Flex Builder/Eclipse Workspace Without Importing Anything (Update)'

Subscribe to comments with RSS or TrackBack to 'Moving a Flex Builder/Eclipse Workspace Without Importing Anything (Update)'.

  1. PomCompot said,

    on January 26th, 2010 at 7:01 am

    This method doesn’t seem to work with Eclipse 3.5. There is no more location information in the .location file, only dependencies now.

  2. Joeflash said,

    on January 27th, 2010 at 1:54 am

    Yeah, it was an early test, more of an experiment than something really viable.

    Funny thing is, tried just simply moving the entire workspace directory over to another machine the other day, and wow it worked, not quite sure why.

  3. Andy said,

    on March 23rd, 2010 at 8:36 pm

    Thank you very much for this post! It was exactly the last but decisive hint to finalize my automatic workspace creation. I’m running Eclipse 3.51. There are no .location files anymore (as PomCompot remarked), but there is only one file, called 3.tree, or 4.tree, or whatever number… I wrote a Java program that copies a whole workspace to another folder and substitutes in each file the directory and also the project names through something different (desired…). And as you figured out, in this special binary file the byte before the string must be replaced through the length of the replacing string.And everything works fine :-) Thanks mate!

  4. Joeflash said,

    on March 23rd, 2010 at 10:43 pm

    Hey, that’s cool. Could you share that Java program, maybe on your blog (with a simple executable for Java dummies like me? :)



  5. Gayatri said,

    on August 5th, 2010 at 10:34 am

    Found a simpler solution here

  6. Joeflash said,

    on October 24th, 2010 at 6:59 pm

    @Gayatri LOL, considering I wrote that article, I think we’re talking about the same thing. Thanks for sharing.

  7. MatthiasB said,

    on February 16th, 2011 at 12:28 pm

    Thanks for pointing to this directory! With a simple bash-script plus use of sed the cumbersome hex-editing will be much easier: Just cd into \{workspace dir}\.metadata\.plugins\org.eclipse.core.resources\.projects\ and run the following statement:
    for i in *; do echo $i; cd $i; sed -i ’s|URI//file:/|URI//file:/|’ .location; cd ..; done

Leave a Reply