In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Dag-Erling Smørgrav) writes:
: "M. Warner Losh" <[EMAIL PROTECTED]> writes:
: > rm doesn't have to live in the chroot. Consider
: > chroot /some/path/to/a/chroot rm -rf /
: > in this case, everything under the /some/path/to/a/chroo
# [EMAIL PROTECTED] / 2004-10-03 02:02:26 +0300:
> On 2004-10-02 17:22, Garance A Drosihn <[EMAIL PROTECTED]> wrote:
> > At 8:57 PM +0300 10/2/04, Giorgos Keramidas wrote:
> > >On 2004-10-02 21:23, Lee Harr <[EMAIL PROTECTED]> wrote:
> > >> How about:
> > >> chflags sunlnk /
> > >> ?
> > >
> > >Set
"M. Warner Losh" <[EMAIL PROTECTED]> writes:
> rm doesn't have to live in the chroot. Consider
> chroot /some/path/to/a/chroot rm -rf /
> in this case, everything under the /some/path/to/a/chroot would be
> removed. However, the rm that's running is outside of the chroot.
Wrong, and I'd be
A simple and pragmatic solution is to use alias in what ever shell you are
using e.g. alias rm to rm -i. There used to be a simple "delete" command or
script that basically moved all files into a ".deleted" directory insted of
actually deleting the files - From a practical point of view it does
On Sun, 3 Oct 2004, M. Warner Losh wrote:
[snip]
MWL> rm doesn't have to live in the chroot. Consider
MWL>chroot /some/path/to/a/chroot rm -rf /
MWL> in this case, everything under the /some/path/to/a/chroot would be
MWL> removed. However, the rm that's running is outside of the chroot.
No
Hi, Andrea, regarding inverted page tables:
> Actually, all Power and PowerPC chips have this...
Thanks for pointing that out. I believe the entire
line of IBM virtual memory hardware that supports
IBM's form of "inverted page tables" is all directly
related, if not the same, and descends f
The "rm -fr /" is not dreaded. What is dreaded is running that
command and other equally dangerous "rm" variants by mistake.
Usually, the mistake comes from not paying attention to what you
are typing or where you are in the directory hierarchy (for example,
"rm -rf *" is probably much more likely
In message: <[EMAIL PROTECTED]>
Tillman Hodgson <[EMAIL PROTECTED]> writes:
: On Sat, Oct 02, 2004 at 07:29:51PM -0600, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > Tillman Hodgson <[EMAIL PROTECTED]> writes:
: > : It'll never work, though, that's the thing.
In <[EMAIL PROTECTED]>, Ryan Sommers <[EMAIL PROTECTED]> typed:
> Edwin Groothuis wrote:
> >On Sat, Oct 02, 2004 at 11:19:28AM +0300, Giorgos Keramidas wrote:
> >I'm not so much worried about 'rm -rf /', but I'm more worried about
> >"rm -rf *" in my home directory. It happened once because I was t
In <[EMAIL PROTECTED]>, Giorgos Keramidas <[EMAIL PROTECTED]> typed:
> John Beck, who works for Sun, has posted an entry in his blog yesterday
> about "rm -fr /" protection, which I liked a lot:
> http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection
>
> His idea was remarkably simple,
On Saturday 02 October 2004 09:51, Giorgos Keramidas wrote:
> Yes, so? Does it mean we should always point guns at our feet and hope
> that we don't accidentally pull the trigger because some unlucky event
> made us jump a bit up?
It just seems pointless to prevent yourself shooting yourself with
On Fri, Oct 01, 2004 at 08:34:37PM -0700, Bruce R. Montague wrote:
> proposed. Instead of having a page table entry for
> each page of virtual address space, these systems
> have the equivalent of a page table entry for each
> page of _physical_ memory. All addresses are effectively
[...]
> disk-bl
The problem can be solved by installing only slow disks and mounting
filesystems in sync mode. As it takes so long to delete files in this
environment, you have plenty of time to hit ctrl-c when you realise what
you've done.
;)
___
[EMAIL PROTECTED] ma
13 matches
Mail list logo
