I'm not sure how I managed it, but while pulling and merging the latest changes from Mercurial repositories on several machines, I somehow managed to blow away all of the uncommitted changes to one of the files in my working copy.
It's my own fault because I've lost work enough times to know about the emacs variable version-control, which, when t, tells emacs to keep multiple versions of the tilde backup files. (I managed to blow away the original tilde file before I noticed what had happened, so I couldn't use that.)
You can set this variable with (setq version-control t) in your dot-emacs (~/.emacs.el, in my case) file. Or you can do M-x apropos, type in version-control, click the bolded version-control in the frame that opens, click customize in the next frame that opens, pick "Always" from the value menu, and hit "Save for future sessions.". (I prefer the former approach.)
Emacs will thereafter save numbered foo.c.~1~, foo.c.~2~, foo.c.~3~... backup files instead of wiping foo.c~ each time. You can use these to recover from errors like this.
Some people dislike the idea of having lots of ~ files littering their directories. These people must enjoy losing data. Even if you never make a mistake, the software you use must have bugs in it. By all means, do a rm *~ periodically, but do be sure you know your code is committed somewhere, first.
Switching on version-control did nothing to restore the file I'd already lost, of course. To find that, I hard-rebooted (you will want to reboot immediately or the old file risks getting overwritten) into Linux. (I was working in Cygwin on Vista due to network-card issues that do not bear getting in to). I grepped the raw Windows partition for a string I knew was in the file. The grep command was something like this:
grep -a -C 1000 OPTIONAL /dev/sda1 > /root/optional
OPTIONAL was my string and /dev/sda1 was my partition. -C 1000 tells grep to dump 1000 lines of context to each hit (the file I wanted was only a few hundred lines). If you want to monitor the progress of your grep, find its pid with ps, go to /proc/$pid/fd and do an ls -l to find the fd of the file grep is searching (probably 3), and then cat /proc/$pid/fdinfo/$fd to see grep's byte-position in that file.
I then gzipped grep's output, saved it to a flash card (Windows can't read my Linux partitions and Linux can't write my Windows partition), and rebooted into Vista.
If you have a fairly-generic query string like mine, lots of spurious hits will show up. I skipped these by re-grepping the file for other strings that I knew should have been there. I found a mostly-complete copy of the version I wanted and pasted in the appropriate bits. And then I made darn sure to commit my changes.
- ► 2010 (40)
- Amazon: mostly win. Windows: bleh.
- Public service announcement
- Don't ask questions in Windows filenames.
- Oh wow
- That seems a tad high
- "It's amazing how much can be accomplished when on...
- EPIC saving data FAIL
- Lie back and think of Canada
- Open-air pharmacy
- Geez, has it really been that long since I last us...
- Twitter: sheer win. On degeekifying the geekery.
- Dovecot gotchas
- ▼ July (13)
- ► 2005 (20)
- ► 2004 (27)