Accidently deleted the wrong folder from Netbeans! Can it be recovered?
You can Start with this simple tip :
1- Right click on the folder/directory that the files had been deleted.
2- Choose Local History – Restore Deleted
3- Done
If it doesn't Work you will need to use a recovery software :
I highly recommend R-Studio, the demo version might be able to recover your files: r-studio.com
Or you can also use recuva
If you accidentally delete a folder on Netbean, the way to recover it is as follows. You can't revert deleted folders but you can revert deleted files. Follow these steps.
Recreate the folder you deleted in your Netbean project. (You may
not be able to create the folder within Netbean, in that case you
can use mkdir command to create the folder )
Right click that folder in Netbeans and go to History -> revert
deleted (you should see a list of deleted files that relate to that
particular folder.
Repeat for each folder and sub-folder
Note: This solution work for both Windows and Linux.
Source : follow this link.
I had the same problem as well and get it solved with the solution of this post.
Related
where can I find .git folder to delete a repo on my system. I opened my local disk as a repository and I have about 5k changes to make.The thing is if I check my git account my local disk is not showing as a repo so i really dont know what is going on. Any solution will be welcomed.
Among the "5k changes", select a file and open it in your file browser. Enable hidden files/folders. Start moving up the hierarchy of that path, i.e., keeping going up in the parent directory of the file.
You'll find the .git folder somewhere. Check its creation date. If it's recent, delete it. Be careful not to delete any commits you had made in some project.
I accidentally deleted a folder with the project. Restore failed using Recuva (which is strange, I specifically did not touch the folder after deleting to avoid accidentally prezapisat sector). It can store backups Eclipse projects? Can I still recover your project?
If you deleted a folder within the project, you may be able to use Eclipse Local History to recover it.
Right-click on the folder or project containing the files/folders you want to recover
Select Restore from Local History...
Select the files you want to recover, and possibly the edition (save revision)
Press Restore
I was following the remarks from this SO Post to "Update" my working copy with the lastest revision checked into our SVN repo.
This made perfect sense as it is the same way I would do it using TortoisSVN. Click Update and you get most recent updated files. However, there was a file I deleted from JBoss Developer (eclipse) and was expecting that using the Update option in JBDS would restore the most recent version of that file from the SVN
However, instead it just told me a conflict existed (file deleted from working copy, but exists on repository) and did not download it like it would with TortoisSVN.
So my question is - how do I get it to update where it actually redownloads the file I deleted?
With TortoiseSVN, if you simply delete a file then it becomes "Missing". If you delete a file in Eclipse, it tells Subclipse you deleted the file so it runs svn delete. The equivalent of taking the Delete action in TortoiseSVN. When you do an update, missing files are restored in your working copy, but deleted files are not -- because you said to delete it.
You are getting something else though. In your case, there was a newer version of the file in the repository. Because it is marked deleted locally, that is a tree conflict. If you did the Delete action in TortoiseSVN you would see the same.
The tree conflict is so that you are aware that the file you deleted has been modified by someone. So maybe you want to reconsider the delete etc. The Team > Show Tree Conflicts option will show all tree conflicts and provide option to resolve it.
Using the Egit plugin, is it possible to permanently remove a file from source control without deleting the local copy?
I.e., is there a GUI action equivalent to running "git rm --cached"?
(Edited to simplify question)
I have found the answer. Team->Untrack is indeed the equivalent of "rm --cached". However there is a known bug which produces weird behaviour when you untrack and then try to commit.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=363405
Team -> Advanced -> Untrack
did the job (git rm --cached) for me.
I had the same problem, after not initially including directories and files in .ignore. I also tried "Untrack" and "Remove from index" possibility, non of which helped(due to the still unresolved Egit issue).
So, in the end I deleted files locally (leaving the project all in bugs), committed and pushed it to the github, and then undid the delete locally and added files to .ignore.
Very unelegant, but it worked.
I lost a lot of time and nerves on it, and I hope this helps someone.
Another option, similar to what Sri Sankaran suggests in the comments, is to update the index in order to assume no modification to your config file:
On the preferences, in Egit, you can list "assumed unchanged" files
:
The file remains versioned and on the disk, but no modification will be detected on it.
If you need to delete invisible folder(or file) from eclipse project:
Add folder(or file) to .gitignore file;
Replace folder to another directory
Team add to index, commit and push
Replace folder(or file) to the project folder
I'm looking for a way to convince Eclipse that a directory has indeed been removed from the CVS repository, permanently?
With regular command line CVS I would just edit CVS/Entries in the directory's former parent. With Eclipse, I've tried removing the directory from the Project Explorer view, removing the appropriate line in CVS/Entries, recreating the directory in PE so that it might be removed on update or synchronization, synchronize without recreating the directory, and probably other things that I've since forgotten, and nothing worked.
The directory has been entirely removed from the CVS repository, so I'm not talking about just pruning empty directories here. The error I am seeing is:
The server reported an error while performing the "cvs update" command.
Project: cvs update: cannot open directory /usr/local/cvsroot/one/two/three/removed_directory: No such file or directory
My project contains all of the contents from /usr/local/cvsroot/one/two. I do not get this error when I navigate to "three" and update from there. I only get it when I update from the project root.
One (quite imperfect) solution for this problem is, beside to check-out the project again, to remove CVS information stored by Eclipse.
Go in the right-menu under the project > Team > Disconnect, and check the radiobutton "Also delete the CVS meta information from the file system". Now your project is unshared and has no more CVS information into it. Then you just have to do Team > Share project, select the previous repository location, and you're done (CVS will detect by itself that the project is up-to-date and won't update nor commit anything, of course).
A folder that has been deleted in the cvs repository by hand won't then be proposed anymore by CVS under Eclipse to be commited.
Beware that on a big project with many files, depending on the speed of your network, the re-share may take some time.
Sometimes it may indeed be easier to delete the project and pull it off again from CVS.
I fought this same thing for several hours a couple of separate times. I just gave in and re-checked out the project. That seemed to work like a charm
Handling of directories in CVS is not perfect. This and many other reasons caused in creating more complete SCM tool subversion.
CVS can create directory, but can not remove it. From CVS point of view, to remove directory you need to remove (cvs rm) all files in directory. But directory is still present in CVS and there's no way to remove it. Hovewer, CVS propose a "hack" to hide such "deleted"/empty directories by executing "cvs up -P" (see here).
So, for CVS command line, I wouldn't mess with parent directory CVS/Entries file, but rather use "cvs up -P" described above.
The directory will be listed in the CVS/Entries file under the parent directory. Remove the entry in the Entres file and the directory. Eclipse should recognize the directory has been removed.
Refactoring directories in CVS is problematic. Due to the way CVS handles history one of the following usually applies:
The history of files moved to new locations appears to disappear. (It is located in the history of the old location.)
The history of files is retained, but files appear moved when checking out versions prior to the move. (Files were moved in the repository, rather than in a sandbox.)
Removing or moving directories in the repository generally creates problems for clients. It helps to retain directories and only move or remove files. Normal processing moves deleted files to an Attic sub-directory.
In the Eclipse CVS synchronization perspective, did you try the 'Override and update' option?
If the files/folders are already deleted on the repository, from the Eclipse project perspective, "replace with"->"latest from HEAD" on the folder containing deleted elements