Interesting points, thanks! Since shred cannot do anything useful with a symbolic link there are only two (no, three) possible courses of action:
1. Dereference the link; shred the thing it points to. 2. Unlink the symbolic link 3. Refuse to do anything At the moment then, shred does (1). shred -u shreds the file and then truncates it. The -f option is not needed. I think option (2) is inconsistent with the other things that shred does; it scrambles things but (by default) doesn't delete them. The principle of operation of shred(1) is that it is not reversible. I always look extra carefully at stuff I'm putting in the shredder, to make sure that really nobody needs it. It might be reasonable to require shred to refuse to do anything with a symbolic link unless the -f option is given. The rationale for this would essentially be that the cost of a mistake on the part of the user is huge, and (so the argument would go) this potentially changes the balance between "trust the user" and "protect the user". (Being Unix-y, coreutils goes in mainly for "trust the user"). So interpreting your point a bit freely, I guess you'd prefer this: shred symlink: yields an error message; nothing is done shred -u symlink: likewise shred -f symlink: shreds the file the symlink points to shred -u -f symlink: shreds the file the symlink points to, truncates the file, but leaves the symlink alone (this is the current behaviour we see without options) This change is not by any means obvious; for example, it removes the current protection that you get in this case: ~/tmp$ rm -f foo bar ~/tmp$ echo hello > foo ~/tmp$ ln -s foo bar ~/tmp$ chmod 400 foo ~/tmp$ ls -l foo bar lrwxrwxrwx 1 james james 3 2008-09-20 15:25 bar -> foo -r-------- 1 james james 6 2008-09-20 15:25 foo ~/tmp$ shred bar shred: bar: failed to open for writing: Permission denied ... if we are using -f to tell shred to follow the symbolic link, there is no extra option needed for "yes, really shred a read-only file". Personally, I think that the loss of this last protection is worse than the protective effect of not following symbolic links by default. So if these are the only possible options, I would prefer to leave things as they are. An alternative would be to add -P and -L options, but the current default is like -L, so this change also would not be without problems. Thanks, James. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
