On Wed, Jul 20, 2011 at 10:15:55AM +0100, Brett Parker wrote:
However, my original problem, 'rm -fr' *doesn't* remove a directory which itself is read only, if I am the user who owns the directory and files but if I get root privileges I can - what happens is as follows:-
chris$ ls -ald fred dr-xr-xr-x 2 chris chris 4096 2011-07-19 17:34 fred^^^ directory not got write perms, therefore you can't delete the files *in* it, if it can't delete the files in it, it won't remove the directory (for obvious raisens).The directories need write permission, the files don't.
Yes, I realised the reason for it no working, but was surprised that 'rm -fr' didn't override it.
You can simply do: find fred -type d -exec chmod u+w {} +
I can simply do 'chmod -R +w *', no need for the find. :-)
chris$ rm -fr fred rm: cannot remove `fred/yyy': Permission denied rm: cannot remove `fred/zzz': Permission denied chris$ sudo -s [sudo] password for chris: root$ rm -fr fred root$ ls fred ls: cannot access fred: No such file or directoryYes, that's because root has a mostly get out of jail free card, permissions checks generally go "ah, it's root, sod it, yeah - you've got permission to do that", where as a normal user is bound by the usual filesystem rules.
Which seems 'wrong' to me, OK, I realise "that's how it is" but it still feels wrong for root to be able to remove files in a read-only directory that is owned by root. In fact a simple 'rm' as root removes files in a read-only directory without any warning! It makes directory permissions pretty irrelevant to root!
This is *NOT* something special in rm, this is filesystem level. Ergo, it wouldn't be documented in the rm man or info pages.
So I can't read the man page for a command and trust that it actually does what it says? Normally I'd expect a notes section that mentions exceptions at least, how else can one find out what a command does in any particular situation? It used to be that the man pages were almost definitive but no more apparently.