Using Visual Studio Code Version 1.8.1 how do I restore a deleted file in the recycle bin?
It uses the normal trash bin of your system. So you can grab it our of there.
In Windows you find it in the explorer, in Linux it is as well in Konquerer / Nemo / ...
First go to Recycle Bin of your local machine.
Your VS code deleted files is there in Recycle Bin.
So, Right click on deleted files and select-> Restore option then your deleted files
will be automatically restored in your VS code.
If you just deleted the file, know that VSCode 1.52 (Dec. 2020) will support:
Undo file operations in Explorer
Explorer now supports Undo and Redo for all file operations: delete, rename, copy, move, new file and new folder.
Make sure the focus is in the Explorer and trigger the Undo or Redo commands and your last file operation will be undone or redone respectively.
Keep in mind that we have separate undo stacks for the editor and the explorer and we choose which one to undo based on focus.
Running on Ubuntu 18.04, with VS code 1.51.0
My deleted files from VS Code are located at:
~/.local/share/Trash/files
Every deleted file have a corresponding .trashinfo file which contains details about where the file is deleted from and deletion date and these are located at:
~/.local/share/Trash/info
More info here.
To search for your deleted files:
find ~/.local/share/Trash/files -name your_file_name
In case you deleted files form a mounted ntfs filesystem, they will be located at:
/path_to_mounted_fs/.Trash-$UID
You can get $UID by doing echo $UID in your terminal.
Hope my case helped!
Click in empty space of VS Code's explorer (it's where you see files listed vertically) and press undo Ctrl + z
It'll recover your permanently deleted files too.
VS Code is a lifesaver. ✌
I know the OP says Recycle Bin. What I do though is recreate the file, especially if it's a single file. And when in the file, I just press CMD+Z (I'm on a Mac) and I get my file back.
Recreate the file in the same directory from where it was
deleted.
CMD+Z inside of the newly created file.
I accidentally discarded changes in the Source Control in VS Code, I just needed to reopen this file and press Ctrl-Z few times, glad that VS Code saves your changes like that.
If you can't find your files in the Windows Recycle Bin as it happended to me
(debugger went rogue and deleted the project folder)
look in the %APPDATA%\Code\User\History\ subfolders sorted by date modified.
There I could retrieve my seemingly lost files.
who still facing the problem on linux
and didnt find it on trash
try this solution
https://github.com/Microsoft/vscode/issues/32078#issuecomment-434393058
find / -name "delete_file_name"
If you have permanently deleted files, on macOS, you can see the history (the last month I guess) in $HOME/Library/Application Support/Code/User/History/. You will have to find your file(s) by looking at each entries.json file in every subfolder and rename the last version of your file.
There is probably a similar way on windows and linux but I don't know the precise paths.
I tried most of the options above but none worked.
What worked for me was clicking and highlighting the folder where the file was deleted from in vscode. Then while it is selected, hit CTRL + Z.
This works on windows.
Hitting CTRL+Z without highlighting that folder didn't work.
Just look up the files you deleted, inside Recycle Bin. Right click on it and do restore as you do normally with other deleted files. It is similar as you do normally because VS code also uses normal trash of your system.
While pushing a repository to Github through Vs Studio code I deleted whole folder and they were not available in Recycle bin also. Here is how I recovered those files.
For Windows.
The method is to restore the previous version of the Drive in which the deleted file existed
I had deleted files from G: drive, the below images are self explanatory
Open properties menu of the drive
In properties go to previous versions tab,
where you can find the previously stored versions of that drive along with date at time of backup
use open or click on restore to get the previous version of that drive.
Note: Manipulations in the drive after restore point won't be available
I am not sure how I deleted a file in VS Code, and couldn't find it in recycle bin. Found the file using the History feature of File Explorer.
A month recovery can be done in visual studio code
1 Right click on file and
2 click Open Timeline and
3 select file from timeline
4 the last time file saved by you
5 and your last change of the file is recovered
NOTE : Not only last but all the previously saved check points can be recoverd from vs code
For Mac, try to search some parts of the code in the deleted file in the following path:
~/Library/Application Support/Code
I found a deleted file in this folder
~/Library/Application Support/Code/Backups
Yes, I know this question is about VS Code but I think I can help someone.
I permanently deleted a file, and I tried all the tips wrote here with no success. So I had to recover the file from OS Linux following this
grep -a -C 500 -F 'Unique string in text file' /dev/sda
It was asked above if there is a way to disable the ability to delete a file you created with an undo (#rochasdv).
There is a new setting to disable undo for file operations:
Explorer: Enable Undo default is warn, confirmation dialog
You can also set it to disable so that your files/folders will not participate in undo operations.
You can alo set it to allow - the pre-new setting situation.
Currently, this new setting is in the Insiders Build v1.64 so it may be in Stable early February, 2022.
I am working on Windows with a Ubuntu WSL. I permanently deleted a file by mistake and was not able to restore it from the recycle bin nor by doing anything else.
I however, was able to get my files content by going to "Timeline" and see all my previous modification (it will open a comparison window).
Hope it will help somebody.
I had the case that I, accidentally, deleted a committed file (git) with a ton of additional uncommitted changes, and I could not get it back. (two days of work! yeah, I know, commit early commit often, I know ...)
I had no linux trash can setup on my docker instance and was developing via remote ssh.
I tried to recreate the file and then do a ctrl+Z to recapture the changes as some suggested here. This did not work for me.
So after a struggle over an hour I finally gave up and thought the changes to the file were lost.
However,
I discarded the changes in git, that the file was deleted.
And THEN I retried ctrl+Z and boom all the changes previously came back
magically!
I was a happy camper!
If your local directory has git initialized and you have not committed the changes that include the delete, you can use git checkout -f to throw away local changes.
If you completely delete any of the components in angular using visual code, you can restore it
Go to Recycle Bin and restore the deleted component that will be restored in the project.
I have a weird one.
I was working on a project in Eclipse (with CDT) when my computer went blue-screen. I remember saving all the files quite recently before that. The computer rebooted with no problems, but when I opened Eclipse again, the file that I was editing at the time was empty (not deleted, so I can't Restore from Local History). All the other files were intact. What happened, is this a problem with Eclipse or my computer, and how can I retrieve the file?
EDIT: I viewed the file using vim on Cygwin and actually it wasn't empty, it was full of unprintable ^# characters.
Right click on the file and choose 'Replace with > Local History...'. This will show you the last few versions of the file that Eclipse has saved.
Checking local history in eclipse didn't actually show anything, but I did solve it another way. What I did is I went to <workspace>/.metadata/.plugins/org.eclipse.core.resources/.history as suggested here, and sorted the entries by last modified. I scrolled down to the latest entry before the crash, then opened the files inside it one by one until I found the file that was erased.
When I start my Eclipse application (with my custom plugins) for the first time a .lock file is created in the workspace folder .metadata.
If I try to start a second application I get the correct error message "Workspace cannot be locked". The .lock file prevents me from starting multiple applications with the same workspace.
And if I manually delete the .lock file while an application is running and then try to start a second one it works. That is ok since I manually removed the file that prevents me from that.
Here is the strange part:
When I close the application the .lock file is not removed, but I can still start another Eclipse application so it doesn't seem to care about the .lock file at that point.
Why isn't the .lock file removed after the application is shutdown and how does it know that the workspace is not in use?
How can I manually check if a workspace is in use? The .lock file is apparently not a safe indicator.
Eclipse does use the .lock file but it also acquires an actual 'lock' on the file. This is usually done using the Java FileChannel tryLock method which acquires an operating system level lock on the file:
RandomAccessFile raFile = new RandomAccessFile(lockFile, "rw");
FileLock fileLock = raFile.getChannel().tryLock(0, 1, false);
The tryLock method throws an OverlappingFileLockException if the file is already locked by another Eclipse.
When Eclipse shuts down the lock is released and the file closed.
It is not necessary to delete the lock file so this is not done.
There is an environment variable osgi.locking which can be used to change this behavior.
Full code is in org.eclipse.osgi.internal.location.Locker_JavaNio
My understanding of the lock file mechanism is this:
When a workspace is opened in an instance of Eclipse, Eclipse first checks for the existence of a lock file. If one is present it tries to delete it.
Success deleting the lock file indicates that no currently-running instance of Eclipse is using that workspace, so this instance can continue on; it creates a new lock file, holding it open while that instance is running.
Failure to delete the lock file indicates that some instance of Eclipse is currently running using that workspace; since that other instance still has the file "open" the new instance can't delete it.
On normal shutdown, Eclipse releases the file, but does not neecssarily delete it. Thus, later Eclipse instances are free to delete it upon start-up.
If Eclipse crashes or does not shutdown normally, the lock file is also released (since the Eclipse process that held it is terminated), again allowing later instances to delete it during their startup.
In a big old, Android project, this morning I added a new activity class and a new XML layout file. A little while later I started getting some weird build errors so I decided to shut down Eclipse to restart it (because that often fixes weird Eclipse problems). But Eclipse failed to shut down and hung saving the workspace. I had to kill javaw to get it to die. See Eclipse leaving stuff behind that I can't kill for details.
When I reopened it I discovered that my new files were no longer in the project! The files still existed on the disk. So I looked up how to save the workspace explicitly in the Eclipse wiki and it said . . .
Note that the most essential information in the workspacesuch as
newly created files and folders within Eclipseare always stored
on disk immediately. Saving the workspace simply involves storing away
metadata, such as markers, and its in-memory picture of the projects.
The workspace is designed so that if a user pulls the computer power
cord from the wall at any moment, the resource tree will still be in a
good state so that the workspace will be able to restart in a
consistent state with minimal loss of information.
... obviously this wasn't true this morning so how do I prevent a repeat of this problem?
The files are saved immediately but the metadata contains the information about which files are in the workspace. If the close fails this may be lost. The files are still there but Eclipse does not know about them.
Using 'File > Refresh' (with nothing selected) will refresh all the information about the files in the workspace.
In eclipse, you can right click in a file and then select Team / Show local history. This shows your local saves and is pretty useful.
Now, I made some changes to a file. I am 100% certain I made them. But they have disappeared. Overwritten by someone else I guess. But when I check my local history I can't see my file changes.
My question is:
Does Eclipse always update the local file history for every save? How reliable is it?
Note: I appreciate people are thinking how can someone else overwrite your files. I am working in a force.com project. When you make changes to a file they are push to a central server. There is source control per se. It is like everyone working with a shared folder.
It depends. Each Eclipse plugin dealing with workspace artifacts can optionally set a flag for local history in its API calls to the workspace resource management when deleting or changing files. If the flag is set, changed files surely get copied into local history. But every plugin can set this flag different.
So even if you might have an editor plugin which always uses local history when saving the edited file, another plugin might delete/modify the file without using local history and therefore interfere.
Summary: Local history is not a reliable way to go back to previously saved versions of a file.
If anyone else runs into this issue, check to make sure you didn't accidentally edit a file in a build or target directory. For instance if you are working on a jsp page and make edits, swear you changed it but they are no longer there in the editor or the local history when you open the file, check to make sure you weren't editing the built version by accident.
This sometimes happens if you are quick to use ctrl-shift-R shortcut to open resources. To avoid this, you can set your build or target folder to derived by right clicking on the folder and checking the derived checkbox. This will prevent the resource from showing in the Open Resource view which could save you headaches later.
To get the code back, I opened the target version and used undo to get to the edited version.