Rm using .# (recap) and some further thoughts.

[John 'tms' Navarra]

      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 at casbah.acns.nwu.edu