navarra@casbah.acns.nwu.edu (John 'tms' Navarra) (05/09/91)
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.edulyda@acsu.buffalo.edu (kevin lyda) (05/10/91)
ok... to start with, i'm a 20 year old undergrad who doesn't sysadmin a site. i'm thinking of getting unix for my pc and wanted to get some insight in how to administer it. however, this debate about how to delete is annoying.... the people who insist that deleteing by renaming to .# files is wrong are not listening! 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. i seem to remember leafing through a unix manual that stated that .# files were temporary. in fact, when i edit files with emacs my temporary backups are .# files. > 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. please remember jon's article concerning cron functions. you mention it later during this, but you still use this. knowing that users need to sleep, thereby implying a certain time of day where system load is low, having the system bouncing through directories shouldn't be a hardship at, say, 3am. > 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. if it bugs you that much, here's a solution: modify ls! make a -# option for christ's sakes! you are in computer science, right? problem solving. ls -a shows certain hidden files that should stay hid. problem. make ls have two levels of info hiding. solution. > 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. please tell me you see the problem with that. joe schmoe has 5 gifs in his account. he only has room for 4. so once a day he deletes one and undeletes another. now multiply joe scmoe by 100 users. believe me people will do it. you should see the vms users here with temp disk storage. i had a friend knock on my door at 2am so he could log in and access his files on tdisk before a 48 hour period had expired. > 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 user example] one solution: modify rmdir so that you can undelete directories. rmdir tmp would result in a directory named .#tmp. another solution: make it so that rmdir doesn't care if there are .# files in a dir. have it /bin/rm them and then do an rmdir. [More experienced user] one solution: if you rm a .# files, the system can assume you really don't want it. so /bin/rm it. another solution: if you rm a .# file it will become a .#.# file. this is a bad solution but a simple delete script will end up doing this. would the people debating please try to do the following: read. i wasn't the first person to give these solutions to your points. kevin
jik@athena.mit.edu (Jonathan I. Kamens) (05/10/91)
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
navarra@casbah.acns.nwu.edu (John 'tms' Navarra) (05/10/91)
In article <1991May9.191652.26724@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >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." One guy mentioned emacs -- what about people who use vi? My Sun systems stores some temporary mail files in a # form but MANY new systems do not use this .# technology! > > >|> 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. What is stopping people from storing a bunch of stuff in /tmp? That doesn't normally get cleared unless the machine is rebooted. I never said that a user should be allowed to have an unlimited quota on a trashcan directory. Entomb is owned by charon and you can always supply a quota on a person's tomb directory so they cannot delete large numbers of files. You can't do that if you delete files to your home dir. My system has a 1meg quota. I think this really sucks. If I want to get the new version of bash and uncompress and untar it, it takes up alot of space and I don't have much room for much else. But if I must deal with a quota at least I could keep bash on my system for a few days before it was deleted if i use entomb. > > > 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. so this is what you are telling me if I want to use undelete: 1) I have to put up with .# files 2) I have to make some alias for ls -a so I don't see .# files 3) I still have to wait around if I delete large numbers of files and want to do an ls -a because the dir is huge. 4) I have to make rm and rmdir aliases to insure it works right. 5) I have to run a cron job every night to hunt down these files. 6) I have to put up with the quota restrictions. 7) if I really want to delete a file I have to use another command so the stupid .# file is not in my directory. (which is the normal case!) and for the big one: 8) I actually have to be an experienced enough user to be able to make all these corrections -- otherwise I could get quite confused in certain instances -- whereas if I used entomb, whether I had knowledge of how it worked or not, my daily operations would not be affected. if that is what you are telling me, then I say IT's STUPID! > > >-- >Jonathan Kamens USnail: >MIT Project Athena 11 Ashford Terrace >jik@Athena.MIT.EDU Allston, MA 02134 >Office: 617-253-8085 Home: 617-782-0710 -- From the Lab of the MaD ScIenTiST: navarra@casbah.acns.nwu.edu
asg@sage.cc.purdue.edu (The Grand Master) (05/13/91)
In article <1991May9.191652.26724@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: }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. Of the University systems to which I have had access one time or another, (well over 50) only one has a crontab entry which deletes .# files. Though it is not a new or unusual idea, it still is present on (my guess of course) << half of the UNIX machines in the world. While this does not make it an absurd idea, it does most certainly make it non-standard. } } } 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. So what? So the user can use it as a temporary archive. If you read the description of entomb, however, you will note that this problem is dealt with if file space becomes important. The default is to allow the files to remain 2 days. But as the filesystem gets more full, this time limit gets smaller and smaller. } }|> 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 }% To explain why this is absolutly horid, we must first examine the reason behind: % rmdir /tmp tmp not empty: not removed The purpose of this is to insure that you do not remove a directory before moving any important files out of it. Let's say I use Jon's method. If I have a directory project, and a file in that directory called important, I could rmdir project, thinking that I already moved important to my save directory. Say I now go away for a coupla days (to visit John Navarra at Northwestern or something). When I come back, my important file is gone, and I have no idea where it went. Using the normal method, this would not have occured. } }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. In John's scenario yes, but not in mine. }-- }Jonathan Kamens USnail: Bruce --------- ### ## Courtesy of Bruce Varney ### # aka -> The Grand Master # asg@sage.cc.purdue.edu ### ##### # PUCC ### # ;-) # # ;'> # ##