|
Halp my computer BSOD'ed again... and I lost a file |
Edgar Reynaldo
Major Reynaldo
May 2007
|
Halp! I lost a file I was working on in CodeBlocks when I tried to run my program from the Build Menu Windows 10 Blue Screened on me, yet again. When the computer finally rebooted, my source file Track.cpp had been overwritten with zeros and was essentially empty. How can I recover this file? Things I've tried : 1. Blue Screen Viewer by Nirsoft, only a mini dump file no real info there. 2. Made a post about it on the CB forums here : http://forums.codeblocks.org/index.php/topic,23019.msg156681.html#msg156681 3. Tried EaseUS recovery software. It successfully found (lots) of deleted files, and some copies of Track.cpp but you have to pay to recover a file, and when I tried to Preview the file, it kept showing me randomly changing garbage. Which means it probably destroyed the file in the process, or there were multiple damaged copies, I don't know. 4. Ran chkdsk, no errors. Stop error is SYS_THREAD_EXCEPTION_NOT_HANDLED or some such bs. What else can I do? If all else fails, I can git checkout from master, but that was like 3 days ago and there were tons of changes since then. ARGH My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Dizzy Egg
Member #10,824
March 2009
|
Hello Edgar - I've have some success using "MiniTool Power Data Recovery" - it's free to recover up to 1GB, and does do a pretty good job, however it can be quite a long time to wait for it to finish, but you can then search for your file, and it sometimes works out well. Sometimes it doesn't and my file is lost.
---------------------------------------------------- |
torhu
Member #2,727
September 2002
|
Edgar, do you use a source control tool, like Git? Do you have backups? If not, you really should start |
Edgar Reynaldo
Major Reynaldo
May 2007
|
Torhu said: do you use a source control tool, like Git? Do you have backups? If not, you really should start Yes, Torhu, I do. vvv Edgar said: If all else fails, I can git checkout from master, but that was like 3 days ago and there were tons of changes since then. ARGH Hello Dizzy Egg, nice to see you haven't gone yolk up. I've tried pretty much all the recovery software there is out there, but since the data was overwritten with zeros, there's nothing short of forensic science that could restore that file. :/ I just used 'git checkout Track.cpp' and it reverted to like a week ago now. Lost two functions, one was really complex, but gives me a chance to rewrite it better I guess. :/ I guess the answer is commit more often. :/ My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
dthompson
Member #5,749
April 2005
|
Edgar Reynaldo said: I guess the answer is commit more often. :/ I sympathise; quite often when I'm about to make a major change to any code, I instinctually freak out rather than reaching for git. Another (totally retrospective) option would be to get Codeblocks to take snapshots every few minutes. Presumably there's a plugin or something for that? ______________________________________________________ |
bamccaig
Member #7,536
July 2006
|
Note: Git history is only as immutable as you make it. Clean history is easier to understand, but often when hacking on code you aren't yet sure what you're doing will work or you might want to clean it up after. If it takes you several iterations to get things working it can result in some rather chaotic commits that aren't easy to understand. If you learn to use Git's tools fully you will gain the power of amend, cherry-pick, and interactive rebase. These allow you to temporarily store your latest work in Git so it's safe and sound, but revise it later if desired so that in the end you can have a clean and logical set of changes to ultimately reach your goal. Albeit, it seems quite odd that the file would be overwritten with zeros. As much as I enjoy hating on Microsoft, I don't think their OS is crappy enough to overwrite a file with zeros while it's panicking. I doubt Code::Blocks would too, but I guess anything is possible. I suppose you should consider hardware failure too. In which case, Git might not have been able to save you (unless you also sync your changes to a remote clone). -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Edgar Reynaldo
Major Reynaldo
May 2007
|
Well the short answer is if you don't commit it you can't restore it. ;P If I'm going to make major changes I make a new branch. If I get a compiling, stable, running product, I usually make a commit. If I fix a bug or three I make a commit. But when I'm developing a new class, or a large method I will work on it for several hours or maybe even days. That is my problem. More commits more often. @bamccaig My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
raynebc
Member #11,908
May 2010
|
You could also use local/cloud backup options on your source folders if you don't want to commit big changes you're still working on or testing. |
torhu
Member #2,727
September 2002
|
Edgar Reynaldo said: But when I'm developing a new class, or a large method I will work on it for several hours or maybe even days. A simple way of dealing with that is just committing when you have written enough code that you don't want to have to start over again, then just updating that commit by doing git commit --amend instead of just git commit as you keep working. |
Edgar Reynaldo
Major Reynaldo
May 2007
|
git commit --amend Ooh, I will remember that one... dthompson said: Another (totally retrospective) option would be to get Codeblocks to take snapshots every few minutes. Presumably there's a plugin or something for that? I found the AutoSave plugin, which does exactly that. Now set to create a .save file every 5 minutes. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Elias
Member #358
May 2000
|
git commit -a --amend git push --force origin master And no, do not do that or you won't have friends -- |
Edgar Reynaldo
Major Reynaldo
May 2007
|
Yeah, thanks. I just figured out that you can't push amended commits after you've pushed them. I nearly lost two hours of work after screwing up the merge from that. :/ :/ :/ My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
torhu
Member #2,727
September 2002
|
You didn't lose anything, Git keeps abondened commits around for about a month If you have the commit representing the state which you want to return to, just git reset your branch to that commit. If not you can use git reflog to find the commit you want to go back to, and reset the branch to that. Then push it with git push -f to overwrite the remote branch. APPEND: If you want, I can walk you through it on the #allegro IRC channel. I use Git this way all the time at work, and so do probably many other regulars here. |
Edgar Reynaldo
Major Reynaldo
May 2007
|
There's no commit to go back to. I already checked out the latest commit for that file. GIT is powerful but not that powerful. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
torhu
Member #2,727
September 2002
|
No, that's not how Git works. Once you make a commit, that commit gets a unique reference, which is the commit hash. If you have that hash, you can use that to refer to the commit. When you amend a commit, you get a new commit, with a new hash. The old version of that commit is a different commit, with a different hash. If the commit is not on a branch, it will be garbage collect after about a month. So your commit is still there, you just have to know how to find it. Trust me, this is how I use git at work, every day |
MiquelFire
Member #3,110
January 2003
|
So Git has an auto-commit feature? That's handy. I guess it works like the autosave features a lot of software has. --- |
torhu
Member #2,727
September 2002
|
No, it doesn't, what do you mean? |
MiquelFire
Member #3,110
January 2003
|
Edgar thought you meant the file he lost because of the BSOD before he learned about --amend. --- |
torhu
Member #2,727
September 2002
|
Righ... |
bamccaig
Member #7,536
July 2006
|
Git is basically an object database. When you git add, your files are added to the object database as "blobs" and "trees" (AKA files and directories), which are then referenced by the index/staging area for your next commit. When you commit, a commit object is added to the object database, and your branch (if you're on one) is updated to point to that commit object as the new tip of the branch. When you `git commit --amend`, Git creates a new commit from the index (possibly adding new files to it first if you tell it to), and that commit replaces the current tip of the branch. The log message from the previous commit is automatically used. In practice, it's as if you updated the previous tip with new changes. But in reality, the commit ID is based on the contents of the commit itself, the log message, the author, and various other metadata. If any of those things changes, including the commit date, the ID changes and so it is a different object in the database. The database does not delete records when they become dangling/orphaned/detached. Instead, a garbage collection process executes after enough time has passed to search for these orphaned objects and delete them, and then group the remaining objects into a single file for compression. So when you `git commit --amend` your original commit is still there. You can easily recover it if you know the ID. Git should be automatically configured to track updates to branches in a "reference log". By default, it will garbage collect this data after 30 days. You can increase it to be any number of days, or infinity if you never want to lose it (at the expense of more disk space used). `git reflog [ REF ]` will show you the list of updates to the branch. This means when the branch tip is updated to a new commit object, whether that's from committing, resetting, or rebasing. That said, if you `git commit --amend` you're telling Git to overwrite history. You should only do this if your changes have no been shared yet (you haven't pushed), or if your workflow allows for rewriting history (meaning other people should NOT be basing their work on your history because your history could change and that would invalidate their work). I generally consider topic branches rewriteable if I'm working alone on them: at work I regularly rewrite my branches and `git push --force`. This is harmless as long as nobody else is working on that history (including yourself on a second computer). If somebody else is working on that history then they'll need to learn how to rebase after you rewrite history (and as a good rule of thumb, you should communicate to collaborators when you do this). In your case, amending a commit in a private repository or personal project it makes sense to force the push. --force is basically acknowledging that you're rewriting history in the remote repository, and that you understand what that means. You should not be doing it unless you understand what it means, but you definitely should learn what it means because it empowers you to use Git much more effectively. Instead of amending the commit every time I prefer to do something like `git commit -am '!!wip'`. This way I have a series of incremental changes to reach a working state. I can still see incremental changes in history, even though they aren't well organized or well planned. And when the work is done I go back with `git reset --soft BRANCH_BASE` and rewrite it by committing selective changes with `git add --patch` and git commit. In the end, I rewrite the entire branch's history so that it's easy to understand, and clean. A simpler thing to do if it's too hard to sort through it is just to commit everything at once with a single log message. You DO NOT want to merge with rewritten history. That will create a big mess. Instead, you should not have rewritten history in the first place, or else you should rebase/cherry-pick/reset/etc. and rewrite any branches based on it. I recommend you experiment carefully with these features at first. You can shoot yourself in the foot if you aren't careful. A good idea is to take a compressed archive (tarball or zip file) of the entire project and repository before you experiment with new features so that if you do shoot yourself in the foot you can easily recover without any knowledge of the internals of Git. In most case, Git provides you the means to recover data that you've stored in it, but if you don't know how `mv project project.orig && unzip -x project.zip` is a whole lot easier to do. #git on freenode is very helpful with these matters. If you explain to them what you're trying to understand or what you're trying to do they can point you to reliable and detailed documentation for the specific thing you're trying to do, and hold your hand while you do it to make sure you're safe. When we're active in #allegro there are also several of us that can help with a more personal touch (but sometimes the advise you get from #git will be better and safer because they do it daily). Side note: I recommend you reach the official "Git Book" online. It will fill in some of the gaps and correct misconceptions coming from Subversion, CVS, etc. And the Git Internals chapter will actually explain to you the implementation details of how Git works. It's very simple. Which makes it very powerful. But you need to understand how it works to take advantage of that. You should do this even if you don't plan to exploit it just out of curiosity because it's very neat. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Edgar Reynaldo
Major Reynaldo
May 2007
|
Torhu, Regarding the file lost during the blue screen, it is gone. There's physically nothing git can do beside checkout the version I have in my repo. Regarding the screwed up merge, yes the amended commit would be there, and I could rewind to just before the merge that nearly destroyed my work. The process was
commit
edit
commit --amend
push (fail)
pull (conflict)
added wrong versions of files
git commit
shit
looks in CB editor and sees files still open asking me to reload NO!
saves old correct versions and recommits
push
what a mess
My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
bamccaig
Member #7,536
July 2006
|
-- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
|