On Tue, Aug 10, 2010 at 06:53:56PM -0700, Jason wrote: > I just rsync everything once an hour to another machine with a bigger hard > drive, and then do an rsync --delete when the drive gets full. Version > control can be helpful too. What happens if you blacklist a file thru a > symlink, or rm a file thru a symlink? I didn't see anything to deal with > that. The chances of having added the file that you didn't want to delete to > this list is quite small.
Thanks for the feedback. Not everybody has another machine to which to rsync, so many users don't have up-to-the-hour backups. Again, this isn't a replacement for backups, it's intended to be a way to catch stupid mistakes, such as tar does by failing if the user forgot to specify the file list (which is really a catch for users who forgot the archive file name). In the case of removing a symlink to a file it doesn't matter because the original file is the one that counts. If you blacklist a symlink instead of the original, or recursively remove a directory's contents through a symlink to the directory, then in its current state this won't help. Obviously the code could (and probably should) be amended to handle that. I realize that coreutils favors size, speed and correctness over user friendliness, but I think the change has merit in that 1) it's enabled explicitly, so it won't bother anyone who doesn't want it; 2) it's a small change, so it's not bloating the code much; and 3) it could save users from headaches. In other words, we're not really trading anything away except a small size increase. On my system the executable size increased from 50K to 58K (stripped). I bet a good chunk of that came from the inclusion of the hash module. In order to check for symlinks, I don't think we could even use a hash table, so the final code size would likely be smaller.
