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.
Related
When attempting to delete log4j.properties Eclipse undeletes in the very next moment. The file is not used at the moment, no build process is running, the project containing the file is not being deployed. Yet the file is being restored immediately. Even when the IDE and all shell (ie. Git bash) sessions are closed and the file is not open anywhere, it can be successfully deleted using Windows Explorer or Total Commander, but the moment the IDE is started the file is there again.
The intention was to replace the old properties structure with an xml, but I couldn't even overwrite it as upon saving the original content got restored. Any advice on this?
Using MySQL Workbench 6.3.8 build 1228 CE (64-bit), on Windows 10 Pro, version 1803, build 17134.112.
I want to restore my old workspaces in MySQL Workbench. If that is not possible, I will be happy with just being able to access them as text files.
I guess my laptop had an unusual power-off or reset last night. Normally I put it in Sleep mode, but when I opened it this morning it had reset itself: all applications had quit.
I re-opened Workbench, and got this error message:
saying that my workspaces could not be opened.
I can't get the full text of the error message, so I don't know exactly where Workbench is looking, but using Windows Explorer I could navigate to:
C:\Users\JamesBarton\AppData\Roaming\MySQL\Workbench\sql_workspaces
which looks right to me, and contains .workspace and .autosave directories.
I've backed up the Workbench\ directory, and then tried just removing the .autosave directories, to force the use of the .workspace directories, but when I did that, Workbench still just opened one empty tab. The first .workspace directory contains 95 files, including 45 .scratch files totalling 107kb.
Is it possible to check exactly where MySQL Workbench is looking for workspaces?
Can I force it to open a workspace directly, or at least show me why it can't open a workspace? If that is not possible, can I somehow extract the SQL from the .scratch files? Thanks.
Should be easy to recover the sql from the scratch files which are just plain text files. The sql code is not encrypted. Also you can look in the Workbench log file (see Help menu) to see if there's an error message or similar for a specific file. Could be there's some file corruption. Running the file system checker on that disk also might help.
PS: in Windows you can use the clipboard in system dialogs like this one. Just press Ctrl+C while the dialog has the focus to copy the entire text, including the button captions, to the clipboard. That will hopefully give you the full error message.
Even though my desktop has crashed several times in the past 3 years (either power-related or system) this last time was the first time MySQL Workbench had issues with a workspace (apparently the 2 I had open at the time?). When I investigated why I discovered that all the .info and .scratch files in those workspaces were written with only NUL characters so no easy recovery of my tabs is possible. Grrr.
I will have to recover everything from scratch (haha) by going through the sql_history and possibly log folders and copy/paste as necessary back into the GUI.
I have updated many files many times, but the history window is always blank, and if I do right click on the file then "compare with local history..." it always pops up and says "No local history available for selected resource"
When I go to Window ->Preferences > General > Workspace > Local History, I see "Limit history size" is ticked with 7 days, 50 entries per file and 1MB max file size.
However, if i edit and save a file with 10 lines in it, there is no history.
How do I get local history working?
This is a real killer because the groovy eclipse plugin keeps crashing, and then I can't save the file so each time it happens I lose all my changes.
I updated to neon 3, but same problem - no local history.
Update
I didnt realise, its just groovy files for which no local history exists. Unfortunately, this is 99% of my files (grails)
The editor crash you mention and the inability to store local history are both symptoms of the same root problem. The Groovy Editor is losing connection with the Document buffer (the source you see displayed in the editor view). When this happens, a whole lot of capabilities stop working.
Please have a look at this issue: https://github.com/groovy/groovy-eclipse/issues/155
A fresh set of logs and some recreation steps are critical to solving the root cause.
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.
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.