On Fri, 2 Jan 2004 16:29:18 +0000, David Golden <david.golden at unison.ie>
> Still troubling him? If he continued using the machine after the
> incident, AFAIK there's very little chance of any of the undeletion
> tools other people have pointed to working, I'm afraid. One really
> needs to stop, unmount the filesystem, and run the undeletion tool ASAP.
Yeah, I remembered that aspect from a previous from experience, so I
instructed him to do diddly until I could get some help out to him (he's
still on the bus).
Before the rest of this mail, thanks all for the suggestions. Colm, the
problem with the 'recover' tool in this case, is that it only seems to
work with Ext2, and not Ext3 (which is the default filesystem type for new
Red Hat installations).
Saying that though, the link to the 'Recovering Links in Unix'
http://recover.sourceforge.net/unix/ yielded a solution of sorts. Prior to
following those instructions, I replicated the situation he got into.
(i.e. used a old object file as the source file, specified the new object
file as the actual source file).
using grep -a -A[Size before] -B[Size After] "text to search for"
/dev/[device on which file was lost],
I was able to recover the original source code for my little helloworld.c
prog. It recovered a lot of gunk as well, but a quick copy/paste/save/make
backup, and my source was back ;-)
My friend is trying that as we speak, so hopefully he will have some
More about nedit...
> Re: nedit autobackup, which AFAIK defaults to on - did he really manually
> disable it? Silly.
The 'incremental backup' is on by default, but the actual 'Make Backup
Copy' option is not ticked on (my version at least(5.3), [which on further
inspection is an old version - must update]), and the 'Make Backup copy
(again on my version) switches itself 'off' after a program restart (must
really update now).
> Nedit defaults to keeping a backup in filename "~name.c"(yes the tilde
> is at the other end of the name to emacs, e.g. say if the file is in
> your home dir, you might use a silly looking "~/\~name.c" to access it.)
I got him to check that, but to no avail.
> If nedit had a sh**fit it might well be because the incrementally
> updated backup that it keeps in ~name.c++ suddenly stopped corresponding
> name.c++ while it was running - e.g. if he ran the g++ command line in
> another window.
I think it might have been something along those lines alright. Although,
from his description, it was all within the same command prompt window...
>http://www.nedit.org/help/recovery.shtml#Crash_RecoveryWill forward the link to him ;-)
> All in all though, it's the kind of mistake you make once and then stop
> making... Having said that, I'm a heretic that thinks that in this day
> and age of absurdly huge harddrives typical linux distro filesystems
> should think about built-in backup/versioning.
"I am interested in your ideas, is there a News Letter I could sign up
for?" <Bad Homer Simpson paraphrase>
Again, thanks for the help and suggestions.
Richard Eibrand , Tourmakeady
*"And today is only Yesterday's tomorrow" *
*Ken Hensley, Uriah Heep, 'Circle of Hands'*
Email : richard at eibrand.net
Web : http://www.eibrand.net
Phone : + 353 94 95 44 100
Mobile: + 353 87 618 1793
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!