Newsgroups: comp.unix.admin Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!navarra From: navarra@casbah.acns.nwu.edu (John 'tms' Navarra) Subject: Rm using .# (recap) and some further thoughts. Message-ID: <1991May9.025448.25243@casbah.acns.nwu.edu> Sender: navarra@casbah.acns.nwu.edu (John 'tms' Navarra) Organization: Northwestern University Date: Thu, 9 May 1991 02:54:48 GMT Lines: 120 I am a bit dismayed at the debate rising about Project Athena. As the person who started most of this, I would like to say that I personally don't know much about Athena BUT my original post had to do with a guy who asserted that the method he used of removing files on his system was useful. I responded saying that on HIS system which does not work like Athena, the algorithm he uses to saved deleted files is not all that efficient. I made the mistake of criticizing the way this would work on Athena. Now I understand that with your setup at MIT, this method needs SERIOUS revisions to work if it would work at all. I don't neccessarily agree that all users need the privledge of mounting filesystems at there convenience. -- not necc from a security point of view but simply a user point of view. With this permission someone could totally screw with another user that needed to use the machine. You seem to be awfully trusting. But onto more important issues. Athena is NOT most systems and the method of removing files as previously described (.#) has some major drawbacks outlined below. Here is a recap and some further commentary on the discussion about the rm function that was previously discussed in which .# files are kept in the current directory when a user deletes a file. I still assert that this idea is STUPID and here are some of the reasons why: 1) Rm .# does not support users naming files .# anything because they would subsequently be deleted. This is not a big problem since most informed users would know not to name files as such but some novice user might be harmed by this rule which is TOTALLY un-standard. One of the major points of Jonathen Kamen's arguments was that Project Athena is a distributed environment and that the action on one system should realiably be the same on another. Not being able to name a file .# is a non-standard restriction on many computers. (Removing files to /preserve or $HOME/ tmp is not all that standard -but it has been done and does not prohibit the naming of any file. And there is no reason why someone would get confused using it even though it isn't standard.) 2) Rm .# takes a LONG time reaping files from the system because it has to search thru every directory on the system looking for .# files. For a system with a large number of users, this would take a hell-of -a-long-time. But it has been pointed out that some machines are capable with little modification to cron to do this at night quite easily so as not to bog down the system too much. 3) Rm .# files do not hide from ls -a commands. Despite what Jon has said, i don't think this command is all that uncommon. Thus, every time I use this command, I would see .# files from previous deletions Now this is somewhat annoying for directories in which I have deleted small numbers of files (esp since, and I will say it again, 99% of the time when a user types rm filename, he does not want to see this file again, EVER!) So if you use ls -a alot and operate in an environ ment that forces this .# stuff, you will be annoyed plenty! And even for some of you who don't use ls -a that frequently, there are many times when we delete a large number of files in a dir. Now if we do an ls, we will still have to wait around for a while to see non-dot files because the dir is filled with .# files! 4) This problem of deleting large numbers of files brings up a quota issue. Many systems have quotas for its users and deleting files to the current dir still adds onto the quota. It is possible to discount .# files (I think) but why bother if you can just move them to a different dir without a quota or one considerably larger that is not affliated with yours. 5) I thought of this one a little while ago. Say you have a directory tmp with some files in it. Now I will take this example from the viewpoint of a novice and not so novice user. Say I want to get rid of this dir tmp so I do the following: Novice: cd tmp ls: file1 file2 file3 rm * ls [nothing] cd rmdir tmp rmdir: tmp: Directory not empty ????????????? -- I just removed all the files!? More experienced user: cd tmp ls: file1 file2 file3 rm * ls [nothing] cd rmdir tmp rmdir: tmp: Directory not empty [Ah, there must be some . files in there!] ls -las ~/tmp: total 6 1 drwx------ 2 navarra 512 May 8 15:01 . 0 -rw------- 1 navarra 0 May 8 14:32 .#file1 0 -rw------- 1 navarra 0 May 8 14:33 .#file2 0 -rw------- 1 navarra 0 May 8 14:33 .#file3 rm .#file1 mv: .#file1 and /home/u3/navarra/.#file1 are identical ! ???????????? In some cases there might be an option to rm to move whole directories to .#tmp but again, this is pretty useless to do as well. What if you wanted a directory like Cops deleted with all its subdirectories. Then you would have a whole mess of .# directories. Most people do not delete entire directory structures and want them back . So in summary, in most computing environments -- which means environments that wouldn't have the workstation mounting problems that jik was talking about, the entombing procedure is MUCH more efficient and I think easier to understand and correct. Granted, it has some problems but those will be addressed shortly. -- From the Lab of the MaD ScIenTiST: navarra@casbah.acns.nwu.edu