sommar@enea.se (Erland Sommarskog) (03/23/88)
It's funny. First someone posts an article "VMS is bad". Some people, like me, feel obliged to reply: "it's not bad, but Unix is." And so you get a war going. Some people are annoyed of getting these articles, so in their turn they everyone's mailboxes with "Stop the war!", instead of just letting it die by itself. I'm just waiting to see those "Stop 'Stop the war!' now!".... Anyway, the rest of this article is a minor quibble about the delete commands on the systems. You may prefer not to read it. Hey, didn't I warn you????? Rahul Dhesi (dhesi@bsu-cs.UUCP) writes: >In article <36568QAA@PSUVM> QAA@PSUVM.BITNET writes: >>To all UNIX lovers - give me ONE good reason why "rm" is better than "delete" >>to delete a file. > >The VMS "delete" command has some serious flaws. It can't recursively >delete a directory subtree. It will also blindly delete a file even if >it has multiple directory entries for it, thus invalidating them with >no warning to the user. (This is really a VMS file system problem.) >Also, "delete" simply aborts with an error if the file that the user >wanted to delete is write-protected, instead of allowing the user to >override the protection as the UNIX "rm" command does. > >While VMS does have some interesting and useful features, its "delete" >command is surely not one of its strong points. The Unix command "rm" has some flaws to. Since ages I have the symbol Del*ete == "Delete/confirm". With the alias "rm -i" I get the same under Unix. The problem comes when I want to entirely want to delete a group of files. In VMS I just answer "a" to the question. "rm" doesn't know of this. "rm" doesn't know of /LOG, nice to have in command procedures, but also when you are cleaning away lots of blocks, and you want to feel proud on how much you remove. "rm" cannot delete files created before a certain date, or that belongs to a certain user. "rm" does, as far I know, just unlink the file, there is no /ERASE option with which you can clean the disk space. With "rm" you can accidently remove a file which you decided to keep, and therefore have set the protection accordingly. Most of the deficiencies pointed by me and Rahul are fairly to circumvent by applying the command interpreter in question. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP "Si tu crois l'amour tabou... Regarde bien, les yeux d'un fou!!!" -- Ange
arosen@eagle.ulowell.edu (MFHorn) (03/25/88)
I wrote: > Which means DCL has to know the syntax of every command on the sytem. Other people wrote: about CLD files. I didn't say you couldn't do it, but it's much easier in unix. You put you executable in ~/bin or wherever and say "rehash" and away you go. As a personal preference, I think CLD files are bogus. In article <2903@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes: > "rm" doesn't know of /LOG, nice to have in command procedures, but also >when you are cleaning away lots of blocks, and you want to feel proud >on how much you remove. I added a -v [verbose] option to rm which does just this. I can mail the diffs if anyone likes. If I happen to get enough requests, I'll post to a more relevant [unix] newsgroup. > "rm" cannot delete files created before a certain date, or that belongs >to a certain user. It's avoiding the issue, but you can "find . -mtime +3 -exec rm {} \;" to delete any files in the current directory tree more than three days old. Flames on the syntax of find to /dev/null [or nla0:]. > "rm" does, as far I know, just unlink the file, there is no /ERASE option >with which you can clean the disk space. This is a problem, and until someone takes unix security _very_ seriously, it will probably be ignored. Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should be
sef@csun.UUCP (Sean Fagan) (03/26/88)
In article <5683@swan.ulowell.edu> arosen@hawk.ulowell.edu (MFHorn) writes: >> "rm" does, as far I know, just unlink the file, there is no /ERASE option >>with which you can clean the disk space. > >This is a problem, and until someone takes unix security _very_ seriously, >it will probably be ignored. No it is not a problem!!!!! Unix spends free cycles doing a couple of things, one of these being zero-ing out free disk blocks. Whenever you request disk blocks, if they have not been zeroed out, Unix will do this for you, *AUTOMATICALLY*. Got that? You don't have to request that it be specifically deleted. While more secure, it does have some problems (such as you cannot recover a file you just deleted, since it is possibly already dead and buried by then). >Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I >ULowell, Box #3031 | ulowell!arosen | learned how to make it >Lowell, Ma 01854 | | talk" -Thunder Road > RD in '88 - The way it should be -- Sean Fagan uucp: {ihnp4,hplabs,psivax}!csun!sef CSUN Computer Center BITNET: 1GTLSEF@CALSTATE Northridge, CA 91330 (818) 885-2790
arosen@eagle.ulowell.edu (MFHorn) (03/27/88)
In article <1155@csun.UUCP> sef@csun.UUCP (Sean Fagan) writes: >In article <5683@swan.ulowell.edu> arosen@hawk.ulowell.edu (MFHorn) writes: >>> "rm" does, as far I know, just unlink the file, there is no /ERASE option >>>with which you can clean the disk space. >> >>This is a problem, and until someone takes unix security _very_ seriously, >>it will probably be ignored. > >(such >as you cannot recover a file you just deleted, since it is possibly already >dead and buried by then). That's the whole idea, that when you get your prompt back, you _know_ the file is gone, completely. Retrieving deleted files is not an issue of security. Protecting them from disk scavengers is. This is necessary only in environments where security is very important and very tight, so it's possible it will never be addressed in Unix. Andy Rosen | arosen@hawk.ulowell.edu | "I got this guitar and I ULowell, Box #3031 | ulowell!arosen | learned how to make it Lowell, Ma 01854 | | talk" -Thunder Road RD in '88 - The way it should be