[ale] recovering an ext3 drive

Michael D. Hirsch mhirsch at nubridges.com
Mon Jan 20 15:41:33 EST 2003


I'm sorry, but I've rarely read a post in which I disagreed with nearly 
every sentence as vehemently as this one.

On Monday 20 January 2003 02:34 pm, Geoffrey wrote:
> Well I still disagree.  If you choose a program called 'remove' or
> 'delete' or any thing in the vernacular, then by damn understand what
> you're about to do.

Why?  All I want is to get rid of it.  Or maybe I'm using another program 
that removed the file without me knowing it was going to do that.  Why 
should I have to understand the inner guts of every program I use, all I 
want is my file back.  By your reasoning you'd agree with having an  
undelete command if the "rm" command were renamed 
"movethefilesomewhereelsesoidonthavetothinkaboutitanymore".  (In UNIX 
tradition we could name the command mvtflsmwrlssidnhvtthkbttnymr.)

> We all have accidents, but you can't stop everything.  You've got to use
> some common sense.

That's silly.  Since you can't stop everything, you are arguing to stop 
nothing.  

I say that whenever practical computers should "do what I mean".  Typically 
when someone removes (tenchincally, unlinks) a file all they really wanted 
to do was to get the file out of the way so that it would not interfere 
with whatever they are doing.  When I throw things out I rarely pass them 
through a shredder, why should a computer be so different?

> If the expectation is that you must protect the fool from himself all
> the time, systems will get so bogged down with dealing with the loose
> screw behind the keyboard, they won't do anything useful.  Think about
> it.  The ideal solution is, you remove a file.  What REALLY happens is,
> it's copied to a safe place that' not touched.  Just in case the machine
> might crash, it's also copied to a tape.  Incrementally to the tape, one
> file at a time as they are deleted.  What's wrong with this picture???

But no one is saying to prevent everything, just common mistakes.  I think 
everyone on this list has accidentally deleted a file--maybe even an 
important file.  If there is a clear solution that would save people lots 
of angst, why not do it?  Yes, there will still be corner cases it might 
not catch--so what?  

> Do people get behind the wheel of a car without learning to drive? No.

Wanna bet?  They most certainly do.  And even the ones that do learn to 
drive don't become a professional driver.  You are asking (no, telling) 
everyone that they should use a computer with a professional attitude.  
That is just wrong.  Computers should be for everyone, not just the elite 
few.

> Why aren't all cars encased in big soft bubbles, so that there's no such
> thing as an accident?

But by your argument we wouldn't have cars with seat belts, roll bars, or 
crush zones.  "If you drive a car into another car, you must have wanted 
it to kill you."

Everyone should go and read "The Inmates are Running the Asylum" to learn 
just how far our engineer ideas of a good interface are from the real 
world.  This is a classic case of the problem.

Given the incredible speed and storage of modern computers, I find it hard 
to believe that one couldn't design a decent filesystem that would have 
the kind of properties which would make users happy.  Journaling is a good 
start, but undelete is probably just as important, if not more so.

The basic rule should be, when an inode is unlinked, it and its disk blocks 
get moved to a MRU (Most Recently Used) list.  When someone needs to 
relink (a new syscall?) the MRU can be consulted.  To keep the engineers 
happy, the MRU could be limited to some reasonable percentage of the file 
system, or maybe for performance freaks, to a percentage of the unused 
space.  Or, if the designer felt like getting fancy, some kind of decay 
functions so that it attempts to keep all files around for an hour, but 
after that it starts deleting files according to some rule.

I imagine this at the filesystem level, not by putting wrappers around 
"rm".  It shouldn't matter who does the unlinking, the filesystem should 
just keep track.

(I'm imagining this as open source, so if you want to file off this safety 
device, you can get a filesystem that will let you shoot yourself in the 
foot.)

If ext3 had this, everyone would have this capability and few would know 
about it.  Someone like you who never made a mistake would never know it 
was there.  Neither would ordinary users know--all they would know is that 
undelete works.

--Michael

> Joe wrote:
> > Geoffrey <esoteric at 3times25.net> writes:
> >
> > I had this exact same argument with Drew some time ago. I later
> > decided he was basically right, but at the time I didn't want to admit
> > that :-) It's a cultural issue, not a technical one.
> >
> >>ChangingLINKS.com wrote:
> >
> > [snip]
> >
> >>>You imply that making a mistake is "stupidity" and that there is
> >>>some great benefit for people suffering or being punished for
> >>>accidents? Where does that come from? (I hear some doctor in the
> >>>background claiming your parents did this to you).
> >>
> >>There is a gain in experiences such as this.  We all learn from our
> >>mistakes, or should.
> >>
> >>>Darwin's rules should be given a bigger priority than they currently
> >>>do. Why?
> >>
> >>Reference above.
> >
> > (Aside: this is a terrible argument. Darwin's rules are *always* in
> > force *everywhere*.  We get to alter our environment in order to
> > change the survival distribution, but Darwin is still running the
> > show. If you supply tools that permit more organisms to survive, you
> > might find some hidden fitness maxima that would not be apparent
> > otherwise.  Right, this analogy has been stretched some distance past
> > its breaking point now...)
> >
> >>>We don't need to be protected from ourselves. Why not?
> >>
> >>I'm the kind of person that thinks it's quite stupid to sit at a red
> >>traffic light when there are no cars in sight on the road with the
> >>green light.  I'm intelligent enough to make a proper decision and
> >>cross the road safely.  Still, if I do, and there's a policeman behind
> >>me, I'll get a ticket.
> >
> > I'm not quite sure what the point of that is. You're certainly free to
> > break the law if you want to, but we (the society, or the OS, I guess)
> > are then free to punish you. The question is, are the rules you have
> > to play by easy to get along with, or not? The set of rules Windows
> > imposes on the user are, for many users, easier to understand and
> > follow than those imposed by Linux. Yes, that's MicroShaft's fault, in
> > many ways (although Apple surely bears a significant portion of the
> > blame). But those rules are not wrong, they're just different.
> >
> > Also, everyone *knows* the rules of the road. Everyone has to pass a
> > driving test before they get into a car by themselves.  No one has to
> > pass a test on using "rm" before they shoot themselves with it.
> >
> > Really, distros ought to have a "newbie mode" that does something
> > like this (ideally with a per-user binary dir, not /bin):
> >
> > $ mv /bin/rm /bin/really_rm
> > $ mkdir /tmp/Recycler
> >
> > /bin/rm:
> > #!/bin/sh
> > mv $* /tmp/Recycler
> >
> > /bin/cleanup:
> > #!/bin/sh
> > /bin/really_rm -rf /tmp/Recycler/*
> >
> > /bin/undelete:
> > #!/bin/sh
> > mv /tmp/Recycler/$1 .
> >
> > And run /bin/cleanup on every boot. That way, new users will be
> > protected from the most common "rm IMPORTANT.txt" - oh shit!  kind of
> > trouble. They can also clean the recycle bin manually.  They just need
> > to be aware that a reboot will really kill everything they've deleted
> > since the last cleanup.  Granted, this scheme isn't foolproof, nor is
> > it completely analogous to the Windows recycle bin, but it would be a
> > help to newbies.
> >
> > To do it right (that is, make it work across all applications,
> > automatically recover recycle-bin space, etc.) would require
> > changes to glibc.
> >
> >>>We sure don't need to be protected from our own stupidity.
> >>>Why not?
> >>
> >>If we never make mistakes, we'll never learn from them.  Just like the
> >>traffic signal example, there are things I'm capable of doing on my
> >>own. I don't need help.  Another stupid traffic light example.  You're
> >>sitting in the left turn lane with a red light.  The traffic going
> >>straight in your direction has a green light.  There are no vehicles
> >>in sight in the on coming lanes, yet, I must sit at the light until it
> >>turns green.  How stupid is that?  What a waste of my time.
> >
> > Naivete is not the same thing as stupidity. A system that wants to be
> > used needs to be useable by its users. If the goal is for Linux to
> > become a mass-market desktop OS, then "You're stupid" is emphatically
> > not going to work as a customer-support strategy.
> >
> >>>What is benefit of "delete" over "hide"?
> >>
> >>You don't waste the resources.  Besides, if you want to hide a file,
> >>move it to a directory you don't look at.  Remove means remove.
> >>Delete means delete.  Archive means archive.  If you want access to
> >>the file at a later date, choose archive.
> >
> > You are absolutely correct, but users don't necessarily know it.
> >
> > Ideally, this would never be an issue - we'd just have infinite
> > storage. Give it a few years, I guess :-)
> >
> > MicroShaft has captured the desktop largely because it permits naive
> > users to get work done (or appears to, anyway). Leaving aside all of
> > the illegal tactics M$ has used to get its products on every desktop
> > in the world, Windows has a much better *appearance* of
> > user-friendliness than does Linux. Linux, however, is a far superior
> > technical base upon which all of the vaunted "user-friendliness" of
> > MShaft products could be built. So why not do that, and rope in all
> > those naive users? (See OS X for inspiration, perhaps.)
> >
> > Cheers,
> >
> > -- Joe
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://www.ale.org/mailman/listinfo/ale

_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale






More information about the Ale mailing list