🚀 go-pugleaf

Robert Brockway (robert@athena) wrote:
: Juergen Exner (jue@cs.tu-berlin.de) wrote:
: :    Incidentally, the best chance for recovery might have been to turn off the
: :    power for your machine before the MBR had a chance to be updated, and then
: :    use fsck to recover the file system.  On the other hand this could also
: :    corrupt your filesystem beyond repair; it's really a role of the dice.

: : Just stupid! The MBR will only(!) be overwritten if you use /sbin/lilo or
: : DOS fdisk \MBR and it has NOTHING to do at all with the data on the
: : disk.

: What he meant was that if you turn the power off before update flushes the
: data to disk you can prevent the data loss.  This can, and has been done.
: It can cause filesystem damage too, though.  And you're right, the MBR
: has nothing to do with this.

My intention was to refer to the "superblock" not the "master boot record".
Carelessness on my part due to being half asleep when I wrote it; sorry.
The MBR is, of course, the initial physical boot block on the hard drive
which allows partition/OS independent use of lilo or other boot managers.

Incidentally, I have successfully used technique this in conjunction with
fsdb under System V for recovery.  Apparently <474qim$4g0@dingo.cc.uq.oz.au>
does not have much experience with system admin, but that's really no excuse
for the gratuitious flame.

: Juergen Exner (jue@cs.tu-berlin.de) wrote`
: :    Of course the best solution would be to hack the fsck source to recover
: :    recently deleted inodes.

: : And how do you want to keep track on "recently deleted inodes"?

: It coulde be done with the e2fs.  The filesystem would have a special list
: of 'recently deleted inodes'.  Remy Card intends to put undelete into the
: e2fs very soon, perhaps that is how he intends to do it.
:   -Robert

Something along these lines is what I had in mind...though there are other
alternatives as well which might require more user interaction.

-Jonathan-