Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix Recovery Legend (1986)

ee.ryerson.ca

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Unix Recovery Legend (1986)

#31

Post by alcari »

derefr wrote: post #30
TheLoneWolfling wrote: post #23

Earlier quoted context omitted.

Personally, I wish two things: 1) that rm had a (configurable) number of files / directories above which it'll ask you to double-check. 2) that files had a "pleasedontdelete" flag that rm would check and ask about.

> pleasedontdelete flag For some programs (rm isn't one of them), removing the write permission is sufficient to get an interactive prompt when you try to overwrite/truncate/delete the file. I really like OSX's current metaphor, where files that haven't been touched in a while get "locked", and must then be "unlocked" to modify them further. Phrasing it in terms of stability rather than permission makes a lot of sens…

`rm` is definitely one of them, it's just suppressed by the `-f` flag. (examples from Ubuntu)

    $ touch foo
    $ chmod -w foo
    $ rm foo
    rm: remove write-protected regular empty file ‘foo’?
There's also the immutable attribute many modern filesystems support, which prevents the file from being modified unless the attribute is removed.

    $ sudo chattr +i foo
    $ rm foo
    rm: remove write-protected regular empty file ‘foo’? y
    rm: cannot remove ‘foo’: Operation not permitted

Re: Unix Recovery Legend (1986)

#32

Post by ethbro »

derefr wrote: post #30
TheLoneWolfling wrote: post #23

Earlier quoted context omitted.

Personally, I wish two things: 1) that rm had a (configurable) number of files / directories above which it'll ask you to double-check. 2) that files had a "pleasedontdelete" flag that rm would check and ask about.

> pleasedontdelete flag For some programs (rm isn't one of them), removing the write permission is sufficient to get an interactive prompt when you try to overwrite/truncate/delete the file. I really like OSX's current metaphor, where files that haven't been touched in a while get "locked", and must then be "unlocked" to modify them further. Phrasing it in terms of stability rather than permission makes a lot of sens…

That's a surprisingly good idea for UAC too. People would hate that it's non-deterministic (from "how will my program run on a user's system" perspective), but makes more sense than other approaches.

If I'm tapping a file that's been sitting there since the OS was installed and hasn't been touched since... Probably fair to ask me to confirm!

Re: Unix Recovery Legend (1986)

#34

Post by pronoiac »

In the ext2 days, an incident put a lot into lost+found. I had a Tripwire database with file checksums, and wrote a script to checksum the files and move them back into place. I think a handful of files were corrupted, but I got it booting again.

Re: Unix Recovery Legend (1986)

#35

Post by placeybordeaux »

LordKano wrote: post #19

6-7 years ago, a co-worker was doing some work on a server that we were phasing out. It wasn't being used for anything of critical importance, so a Jr level person was permitted to have root. He was actually my colleague and equal on the org-chart but he had less experience with *NIX administration. He was copying directories to the new server and deleting them when he was done. Well... I don't remember the sub-direc…

A week of stress produced this doozy while attempting to upgrade from go 1.2 to go 1.3

[peter@bamboo-sb bin]$ sudo mv /bin/ /usr/local/bin/go1.3 [peter@bamboo-sb bin]$ sudo mv /tmp/go/bin/ /usr/local/bin/go1.3 sudo: mv: command not found [peter@bamboo-sb bin]$ mv -bash: mv: command not found [peter@bamboo-sb bin]$ ls -bash: /bin/ls: No such file or directory [peter@bamboo-sb bin]$ ls -bash: /bin/ls: No such file or directory [peter@bamboo-sb bin]$ ls -bash: /bin/ls: No such file or directory

All during a skype call. It is very recoverable, but I felt quite foolish.

Re: Unix Recovery Legend (1986)

#36

Post by charonn0 »

wsterling wrote: post #33

Why did they not boot from installation/recovery media, mount the drive, copy what was left, restore and copy back the user and configuration data that was found?

> Alternatively, we could get the boot tape out and rebuild the root filesystem, but neither James nor Neil had done that before, and we weren't sure that the first thing to happen would be that the whole disk would be re-formatted, losing all our user files. (We take dumps of the user files every Thursday; by Murphy's Law this had to happen on a Wednesday). Another solution might be to borrow a disk from another VAX, boot off that, and tidy up later, but that would have entailed calling the DEC engineer out, at the very least. We had a number of users in the final throes of writing up PhD theses and the loss of a maybe a weeks' work (not to mention the machine down time) was unthinkable.

Re: Unix Recovery Legend (1986)

#37

Post by pronoiac »

I've considered this problem before. If I remember my research, I'd investigate using bash's built-in echo or printf, and paste encoded versions of binaries into the terminal. To speed up the terminal work, get uudecode, base64, or iconv working. Maybe wget or curl, to fetch base packages and unpack them. Then, say, ssh, and rsync, and selectively restore from backups.

Re: Unix Recovery Legend (1986)

#38

Post by caipre »

Awhile back I read another disaster recovery story, along the lines of recovering a long pipeline command from a long-running process by reading the resident memory of the containing shell. I've not managed to find it, but I think it was posted to HN sometime last year or so. Anyone know about it?
Post reply on HN