Unix Recovery Legend (1986) • Hacker News Board

Re: Unix Recovery Legend (1986)

#21

Post by pdw » Wed, Sep 02, 2015, 8:32 PM UTC

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…

This particular variation was (finally!) fixed in the 2013 POSIX revision:

"If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands."

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm...

Warning: not yet widely implemented outside the GNU world.

Re: Unix Recovery Legend (1986)

#22

Post by rleigh » Wed, Sep 02, 2015, 8:49 PM UTC

GTP wrote: post #4

teddyh wrote: post #3

Earlier quoted context omitted.

"cd" is always a shell built-in. It is not even possible to have a /bin/cd binary which does what "cd" does.

Why is impossible? Maybe I've understood why it is always built in: without it the shell wouldn't be able to navigate through the directory tree to find the executables of the commands. But once the shell has it, I think it would be rendundant (so nobody does it) but still possible to have a /bin/cd that navigates directories.

It's impossible because it simply calls chdir(2). The "current directory" is a property of a process; having it built-in means it changes the directory of the current process. If it was a separate executable, you'd change the directory in a separate child process for that executable, and the current directory of the shell would be unchanged, making it entirely useless.

Re: Unix Recovery Legend (1986)

#23

Post by TheLoneWolfling » Wed, Sep 02, 2015, 9:02 PM UTC

pdw wrote: post #21

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…

This particular variation was (finally!) fixed in the 2013 POSIX revision: "If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands." http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm... Warnin…

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.

Re: Unix Recovery Legend (1986)

#24

Post by bronson » Wed, Sep 02, 2015, 9:08 PM UTC

pdw wrote: post #21

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…

This particular variation was (finally!) fixed in the 2013 POSIX revision: "If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands." http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm... Warnin…

No protection for `rm -rf file.bak ~`?

I'd love to know whoever it was that thought tilde was a good character to use in backup filenames.

Re: Unix Recovery Legend (1986)

#25

Post by Zenst » Wed, Sep 02, 2015, 9:14 PM UTC

TheLoneWolfling wrote: post #23

pdw wrote: post #21

Earlier quoted context omitted.

This particular variation was (finally!) fixed in the 2013 POSIX revision: "If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands." http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm... Warnin…

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.

You can script that all up and call it rm and pop it higher up the user PATH and if you need the pure rm command without the wrapper protection (for say scripts) then can just point to that with the full path.

Re: Unix Recovery Legend (1986)

#26

Post by irishcoffee » Wed, Sep 02, 2015, 9:16 PM UTC

One of my coworkers was out in the field trying to fix a problem on a rhel box.

As root, typed in chown -R nobody:nobody / some/dir/somewhere/

Ended up having to re-image the system. We still give him a hard time about it.

Now I'm wondering if he could have tried to find a more creative solution as displayed in TFA.

Thoughts?

Edit: He hard killed the box right after he typed that in.

Re: Unix Recovery Legend (1986)

#27

Post by bluesmoon » Wed, Sep 02, 2015, 9:18 PM UTC

Many years ago I ran into a similar problem. A technician came in to the office to replace my hard disk with a larger one, and instead of copying my old data to the new one, he started copying the new disk to the old one, resulting in /home now being partially NTFS and partially ext2. ie, it was unreadable in linux and Windows. I documented the recovery process here: http://tech.bluesmoon.info/2004/11/home-is-ntfs.html

Bonus: a year later, at a different company, I was faced with having to undelete source files on FreeBSD (UFS). I documented that as well here: http://tech.bluesmoon.info/2004/08/undelete-in-freebsd.html

Re: Unix Recovery Legend (1986)

#28

Post by bluesmoon » Wed, Sep 02, 2015, 9:21 PM UTC

irishcoffee wrote: post #26

One of my coworkers was out in the field trying to fix a problem on a rhel box. As root, typed in chown -R nobody:nobody / some/dir/somewhere/ Ended up having to re-image the system. We still give him a hard time about it. Now I'm wondering if he could have tried to find a more creative solution as displayed in TFA. Thoughts? Edit: He hard killed the box right after he typed that in.

I suppose he could have tried remounting the device read-only, and then using dd to directly update the inode table to change ownership, but, if he was already root, he could have just chown'ed it again.

Re: Unix Recovery Legend (1986)

#29

Post by schoen » Wed, Sep 02, 2015, 9:31 PM UTC

Someone1234 wrote: post #16

schoen wrote: post #6

Earlier quoted context omitted.

The parent comment's explanation is exactly right (although I might not use "CWD" in this context, because a reader might mistakenly think the working directory is determined by an environment variable). As an example, try python -c 'import os; os.chdir("/")' Notice that the working directory of your shell is unaffected. :-) Or: bash -c 'export foo=bar'; echo $foo

Those examples are trying to change the directory on the shell's child process, not on the shell itself. That being said, aside from a kernel patch there is definitely no official way of doing it. This is the hacky way: http://stackoverflow.com/questions/2375003/how-do-i-set-the-...

I meant for my examples just to illustrate that a child process can't change the working directory or environment of the parent process.

Re: Unix Recovery Legend (1986)

#30

Post by derefr » Wed, Sep 02, 2015, 9:34 PM UTC

TheLoneWolfling wrote: post #23

pdw wrote: post #21

Earlier quoted context omitted.

This particular variation was (finally!) fixed in the 2013 POSIX revision: "If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component) or if an operand resolves to the root directory, rm shall write a diagnostic message to standard error and do nothing more with such operands." http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm... Warnin…

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 sense to me. It's too bad the metaphor isn't echoed in the CLI.