James Youngman wrote: > 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 that shred is fundamentally a different thing than rm. rm simply removes a file from a directory. It doesn't actually do anything with the disk space. The filesystem garbage collects it if there are no other pointers to it. Whereas shred actively tries to make the indicate files unrecoverable. rm doesn't try to make it impossible to get to the file again. Consider this: mkdir a b date -R > a/file1 ln a/file1 b/file2 At that point both files are linked together. Either may be removed and the other will remain. rm a/file1 cat b/file2 ln b/file2 a/file1 rm b/file2 cat a/file1 So rm is not about file contents. There is no believe that removing the file is making it inaccessible. It is just gone from the directory from which it is being removed. rm does not affect file contents. rm simply removes the file from the directory. But what about truncation? ln b/file2 a/file1 : > b/file2 cat a/file1 It is gone. Truncation affects the contents of the file. shred affects file contents in the same way that truncation affects file contents. In which case it should follow the symlink. Symlinks should be transparent. It seems that it would be okay to have an option to avoid tracking symlinks though. But that shouldn't be the default paradigm. It seems to me that if someone is wanting to shred the file then they want the contents to be unrecoverable. In which case it should follow symlinks transparently. editor afile ...I don't want that information to be available... shred afile ...That private information is gone forever... Consider what happens in this case then: touch bfile ln -s bfile afile editor afile ...I don't want that information to be available... shred afile ...That private information is gone forever... cat bfile ...But I used shred on that file! I think conceptually the use of shred is on information not files. This differentiates it from rm which conceptually simply operates on files in a single directory. > I think option (2) is inconsistent with the other things that shred > does; it scrambles things but (by default) doesn't delete them. Agreed. > 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"). Being a new command I doubt there is a long legacy of shred use with regards to symlinks. So nothing serious to break with behavior changes. And I don't feel strongly about shred. But I think creating special cases where particular commands behave different with regards to symlinks that is expected or differently from the main set of commands is a bad trend. Consistency is more important. > 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. Agreed. > 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. Since I expressed an opinion already I will do so here too. I don't feel strongly about adding special options to do special things. Bob _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
