I need help. I was starting to work on a new project in Eclipse and so I decided to rid my package explorer space of any past projects within the IDE. I had 2 projects saved prior to opening the IDE: "new" and "project 1." I proceeded to delete project 1 successfully from the IDE permanently without any issues so I tried to delete "new." "new" was a project directory saved on my desktop and upon deletion within the IDE by right clicking, it deleted random files and folders on my desktop as well as other files I'm not aware of within a second, completely bypassing recycle bin-around 50GB of files. I tried to recover most of the files but they are fragmented and therefore damaged. Is this behaviour normal in Eclipse?
Basically in eclipse when you create a project, you create in a workspace. By default the project gets stored in the work space folder. However you can give a specific directory to save your project
The work space folder will usually have information regarding the projects. In eclipse we have 2 kind of delete. i.e.
1) Logical:- Project will get deleted from work space but there wont be any actual delete of files.
2) Physical:- Complete deletion of project.
I guess you would have opted the second one and the project would be corrupt. May be it had some dependent files outside which got deleted also.
usually when I want to remove the project , I go for soft delete. When I completely want to remove the project then I browse and delete the project folder itself.
You can find other related help regarding Eclipse in
http://help.eclipse.org/indigo/index.jsp
I'm running Eclipse Luna on Ubuntu 12.0.4 in VirtualBox with a Windows 8 host and every once in a while, I will boot up Ubuntu and open up Eclipse to find this:
My projects should be listed in the package explorer but it's all empty and whenever I try to import the project again, it says no projects are found.
At this point, I usually go to my workspace folder and delete the .lock file and rebuild the workspace but is there an alternative to this? This error happens every ~5 times I reopen Eclipse and it has become very annoying. Any help will be appreciated!
EDIT: Okay I just tried deleting the .lock file in the .metadata folder in my workspace and I'm still getting the same error. Any suggestions?
EDIT 2: While closing my currently open tabs, I got this error. The projects that were open were Maven projects if that makes a difference.
so I am a little late for the party, but I fixed that on reimporting my projects.
Under File->Import.. you choose General->Import existing Projects into workspace. On the next page you set your workspace directory as the root directory for importing, which will give you a warning like "Some projects already exist in workspace". Ignore this and click finish.
After that all my projects where back in my workspace.
Good luck
To solve this problem, I re-created my workspace and imported my projects again.
Creating a new workspace is done via:
File > Switch Workspace
This is not an optimal solution, but until Eclipse fixes these bugs, this can save you some time trying to debug your current workspace.
I previously had a very small number of Eclipse plugins installed. So, I quickly headed to the Marketplace and installed my plugins.
And yes, Eclipse's downfall is expected. I personally find IntelliJ IDEs much better.
My Eclipse with GAE broken and works strangely.
So I deleted Eclipse from Application folder, but there is garbage left. I re-downloaded fresh new eclipse, but it runs with old settings, and broken GAE structure remained.
How can I DELETE completely Eclipse from my Mac? (without any kind of settings/plugins/logs etc.)
Eclipse itself will be installed where you've unzipped the file you've downloaded. This directory contains Eclipse.app, configuration/, plugins/ and features/ (amongst others).
Your workspace/ directory (in your home directory by default) contains all your projects and various settings too, in workspace/.metadata/ (see dot files if you want to have a look). Deleting the workspace will delete your own project files of course, so you would need to make sure you have a way to restore them from a clean version (for example from a version control system if you're using one).
If you don't want to delete your entire workspace, it might be worth moving it away and then copying the projects back in, leaving the new workspace/.metadata/ clean, to see if this fixes your problem.
Add ~/Library/Caches/org.eclipse.platform.ide to the list
Im not sure if this is the right place for such kind of questions...But r u using any applications such as "app cleaner"?
if not try it... http://en.softonic.com/s/app-remover:mac
I recently moved my Eclipse workspace directory and now Subclipse complains every time I open a file, dumping to the console something like:
Path is not a working copy directory
svn: '[original (pre-move) directory path]' is not a working copy
No such file or directory
This also happens when I explicitly try to view the history of a file. This persists across SVN cleanups, closing and re-opening Eclipse, etc.
Update, checkin, checkout and so on all seem to work fine, and Tortoise doesn't complain at all, so clearly it's not the SVN metadata that's screwed up, it's some Subclipse-specific metadata. Can anyone tell me how to blow this broken metadata away?
Edited to add: "Team > Disconnect" followed by "Team > Share" doesn't solve the problem.
Edited again to add: I've grepped through the whole .metadata directory and one of the project directories for a unique element of the old path and can't find it anywhere except in .metadata/.log (the error message itself) and some old Findbugs warnings. Very nice.
You need to delete the .syncinfo files. This is easily done (in most cases) by closing and opening Eclipse, however you can also do so manually as in the following:
To delete the cache, close Eclipse. The cache is stored in:
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects/PROJECTNAME/.syncinfo
So you can just find and delete all files named .syncinfo in
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects
Quoted from this article: http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=868799
I just did a "Team -> Cleanup" and this exact error went away! I also got this error because I moved between machines and the path wasn't the same.
Using Eclipse 3.6 and the Subversion 1.6 plugin.
Update in 2016: Still works perfectly with Eclipse 4.5.2 and Subclipse 1.10.
Edited to add: Nope, spoke too soon. This doesn't fix it. Some files just seem not to exhibit the problem.
The following seems to solve the problem:
Team > Disconnect.
Quit Eclipse.
Blow away .metadata/.plugins/org.tigris.subversion.subclipse.*.
Restart Eclipse.
Team > Share.
Not sure how the old path was actually being stored in the plugin prefs, but it must have been in there somehwere. It's kind of pathetic of Subclipse to store absolute paths, but apparently it is.
There's a bug filed on this, or at least on the same error message. No context. Fifty cents says it gets rejected.
I'm sure there are many causes with different solutions, but I found the one that worked for me at Dan Wilson's blog. Simply remove the offending folders from the workspace (probably saving them if they have new content), update (letting Subversion recreate the folders), then move the contents back into the fresh folders in your workspace.
I got the error when I tried to rename a class by changing the case from DAO to Dao in Eclipse.
I had to rename it to something like Dao2 and then was able to rename it to Dao.
What worked for me:
Do a "refactor - rename" on the project => after that do it again to rename it back to the original name.
I was having the same error message using subclipse with javahl on a project that is out of the workspace directory. Changing to svnKit has resolved my problem.
Hard to say without further information.
Did you move the whole workspace or just the content?
Also, you can try creating new workspace from scratch and check out the whole project again.
Alternatively, you may try deleting the .metadata directory and relink the project again using File -> import -> existing project into workspace and then relink the SVN data through Team -> Share projects (with an 's'), or maybe just do this last bit after first disconnecting the project from SVN.
Right click the project folder : Team -> Update to Head
This will bring back the directory. Delete it again and Commit
In my case I had the folders of the projects in the Project Explorer and just had to reopen the project
For me, this error message was caused by an out-of-date installation of Subclipse, and the underlying SVNKit and JahaHL libraries. I have been using TortoiseSVN outside of Eclipse to manage my project directories, and my recent upgrade to the 1.8.x series of (Tortoise)SVN tools broke my working copies for Subclipse.
All I had to do to fix, was go to Help->"Install New Software..." and click "Add..." to add a new update site. I picked the latest update site for the latest release on http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA and upgraded Subclipse from there.
Then all my existing projects just worked, and I could reconnect to the one I had already tried disconnecting from without problems.
I have the same problem
I had a new project, added it to SVN. Then everything works as normal, until I try and refactor-rename any java file, I get:
move D:/dev/sk_ws/ge-parent/ge-core/src/main/java/com/skillkash/ge/beans/Skbean.java D:/dev/sk_ws/ge-parent/ge-core/src/main/java/com/skillkash/ge/beans/SkBean.java
Path is not a working copy directory
svn: Path 'D:\dev\sk_ws\ge-parent\ge-core\src\main\java\com\skillkash\ge\beans\SkBean.java' is not a directory
Now the SVN URL is:
svn://qnap/share/MD0_DATA/svn/sk/ge-core/trunk
and the repository root is:
svn://qnap/share/MD0_DATA/svn/sk
Obviously just sharing the project then trying to move a file using subclipe does not work - it must be a bug. I have to do all my refactoring outside eclipse, and hand edit all the files which are affected.
checkout the whole project to a temp dir, then I copied the first level .svn directory and replaced my working copy .svn folder with this.
http://blog.itopia.de/directory-svn-containing-working-copy-admin-area-is-missing/275
It woks for me.
I had added a png file to my project, but I got this error trying to rename or delete it. Cleaning and refreshing the project didn't do anything.
I went into the svn Team Synchronizing perspective, right clicked on the file and deleted it. That solved my problem.
Right click on the project and select Teams -> Switch to another Branch/Tag/Revision.
Select the appropriate Branch/Tag/Revision that the project should be tied to and click OK.
Give Eclipse some time to process the changes.
Restart Eclipse for the changes to take affect.
I just got this error when I was trying to update some .java files. The problem was I was trying to update the files but the folder that contains that files didn't exist in the path so when I sync and update the folder it works at the first try.
So, dont try to sync files, try to sync the folder.
Sometime ago I had a similar issue. Seems that Subclipse (or Eclipse) stores the absolute path of your working copies. The cleanest solution is to export again your repository to the new path.
If you have non-committed code, then you can copy it on top of the clean export (without the .svn folder)
I too had this issue and I simply deleted the project from the workspace (leaving the files on the files system in tact).
I then imported an svn project into the workspace.
Import->SVN->Checkout Project From SVN.
I used my existing repository location to pull the files in.
This issue was caused when I changed Eclipse editions and used a Subclipse plug-in that was a version ahead of what I should have used.
I uninstalled the newer version and installed the correct older version and all worked well.
After upgrading to the newest GWT/Google app engine I have problems opening my workspace in Eclipse. On startup, Eclipse hangs almost immediately and needs to be closed. This happens only in the workspace where I use GWT with app engine, and I weren't able to consistently reproduce it - sometimes it starts normally, and sometimes I need to kill the proces and restart it. There is nothing in Eclipse error log. Eclipse version is Galileo, running on Windows 7 RC.
Anyone else had similar problems? I googled but Google is not my friend today.
EDIT: Still happens after upgrading to GWT 2.0.1.
I got frustrated with not being able to open my workspace today, and finally solved this by importing projects into a new clean workspace.
Create new workspace and open it in Eclipse (to create .metadata folder).
Close Eclipse.
Manually copy all settings from old workspace (the most important settings are stored in the .metadata/.plugins/org.eclipse.core.runtime/.settings directory). Alternatively, you could use File / Export / General / Preferences in Eclipse, and then File / Import them, but I wasn't able to open workspace to do that.
Open the new workspace.
File / Import / General / Existing projects into workspace. Select root folder of your old workspace, and take care to check "Copy project into workspace".
Restart Eclipse and check that everything in the new workspace is working as it should.
Delete your old workspace.
EDIT: Another, and a bit better workaround which apparently works:
Close Eclipse.
Temporary move offending project somewhere out of the workspace.
Start Eclipse, wait for workspace to load (it should).
Close Eclipse again.
Move the project back to workspace.
I used "eclipse -refresh". Apparently it hangs on refresh something, the lower right corner tells you, what it's doing. For me it was refreshing the gwt runtime in a specific project, maybe trying to find an update or something. If you don't want to reimport your whole workspace, try -refresh or move this project temporarily out of the way.
I just deleted the state.dat file in the GWT project metadata, which seemed to remove the blocking and then triggered a recompilation.
<workspace>/.metadata/.plugins/org.eclipse.core.resources/.projects/<GWT project>/org.eclipse.jdt.core/state.dat
This probably won't serve as a general solution, but it worked for me and it's a lot quicker than having to copy whole projects. Maybe another file will have the same effect. I think the trick is just to "damage" the GWT project metadata enough to have it rebuilt.