Rm using .# (recap) and some further thoughts.
John 'tms' Navarra
navarra at casbah.acns.nwu.edu
Thu May 9 12:54:48 AEST 1991
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
More information about the Comp.unix.admin
mailing list