Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Halp my computer BSOD'ed again... and I lost a file

Credits go to Dizzy Egg and torhu for helping out!
This thread is locked; no one can reply to it. rss feed Print
Halp my computer BSOD'ed again... and I lost a file
Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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 :P

Dizzy Egg
Member #10,824
March 2009
avatar

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. :D

----------------------------------------------------
Please check out my songs:
https://soundcloud.com/dont-rob-the-machina

torhu
Member #2,727
September 2002
avatar

Edgar, do you use a source control tool, like Git? Do you have backups? If not, you really should start ;D

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Torhu said:

do you use a source control tool, like Git? Do you have backups? If not, you really should start ;D

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 :P

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. :/

dthompson
Member #5,749
April 2005
avatar

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?

______________________________________________________
Website. It was freakdesign.bafsoft.net.
This isn't a game!

bamccaig
Member #7,536
July 2006
avatar

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).

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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
It could have been in the hardware cache for the ssd, and if that crashed, then it could be lost.

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
avatar

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
avatar

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.

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 :P

--
"Either help out or stop whining" - Evert

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

torhu
Member #2,727
September 2002
avatar

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
avatar

torhu
Member #2,727
September 2002
avatar

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
avatar

So Git has an auto-commit feature? That's handy. I guess it works like the autosave features a lot of software has.

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red
If anyone is of the opinion that there is no systemic racism in America, they're either blind, stupid, or racist too. ~Edgar Reynaldo

torhu
Member #2,727
September 2002
avatar

No, it doesn't, what do you mean?

MiquelFire
Member #3,110
January 2003
avatar

Edgar thought you meant the file he lost because of the BSOD before he learned about --amend.

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red
If anyone is of the opinion that there is no systemic racism in America, they're either blind, stupid, or racist too. ~Edgar Reynaldo

torhu
Member #2,727
September 2002
avatar

bamccaig
Member #7,536
July 2006
avatar

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.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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

bamccaig
Member #7,536
July 2006
avatar

Go to: