Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!mips!sdd.hp.com!think.com!mintaka!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.admin
Subject: Re: Rm using .# (recap) and some further thoughts.
Message-ID: <1991May9.191652.26724@athena.mit.edu>
Date: 9 May 91 19:16:52 GMT
References: <1991May9.025448.25243@casbah.acns.nwu.edu>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 84

In article <1991May9.025448.25243@casbah.acns.nwu.edu>, navarra@casbah.acns.nwu.edu (John 'tms' Navarra) writes:
|>  	1) Rm .# does not support users naming files .# anything because they
|>            would subsequently be deleted.

  The convention of files beginning with .# being temporary and purge-able by
the system is far older than Project Athena's "delete" package.  Vendors have
been shipping systems that search for and delete old .# files by default for
many years, just as they search for and delete # files, ~ files, and in some
cases a.out and core files.

  You would do well to learn a bit more about the history of Unix and its
current variants before you go around declaring that something both old and
common in Unix is "TOTALLY un-standard" and "a non-standard restriction on
many computers."

|> 	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.

  I've already dealt with this problem; it is a non-problem.

|> 	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.

  Well, then, we'll have to agree to disagree.  I have both "rm" and "rmdir"
aliased to delete in my account, and I know a lot of hacker-types (the people
who are most likely to use "ls -a") at Athena who do the same, and I have
never heard this complaint before.  If you think it's more of a problem than I
do, there is nothing I can do about that.

|> 	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.

  As I have pointed out in a previous posting, allowing users to delete files
into a repository without a quota, and then to restore them, allows users to
use the deleted-file space as a temporary file archive, unless it is
constantly watched by the admins to make sure that this does not happen.

  Yes, leaving the files in the user's home directory takes up quota.  Yes,
this is a CONSCIOUS DECISION in the design of the program.  Users who are near
their quota can do something like "expunge -t 3 ~" to get rid of deleted files.

  It can be argued that the possibility of abuse of alternative directory
archiving of deleted files is outweighed by the advantages of moving the files
out of the user's home directory.  I might even agree with such an argument,
although I would have to think about it some, in which case you're right, this
is a flaw in the way in which we do things.  But it is not, in my opinion, a
major flaw, nor is it enough to call our method "STUPID" as you did in your
posting.

|> 	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:

  You would do well to actually look at our software, which is available in
comp.sources.misc, before making up scenarios that might break it.

% alias rm
delete
% alias rmdir
delete
% cd tmp
% ls
file1  file2  file3
% rm *
% cd ..
% rmdir tmp
%

In other words, if delete is used as it is intended to be used, replacing both
rm and rmdir, it does the right thing in the scenario you described.

  I have already addressed in previous postings all the other points you make
that I choose to address.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710