🚀 go-pugleaf

In article <JARED_RHINE.95Apr6094023@aslan.hmc.edu>,
Jared Rhine <Jared_Rhine@hmc.edu> wrote:
>PFC == Preston F Crow <crow@coos.dartmouth.edu>
>  
>  Michael> I don't like all these rm changing suggestions.  What I
>  Michael> think would be a great idea is the adoption of a command
>  Michael> `trash' with identical arguments to rm, but doing a mac like
>  Michael> trashcan system, where it just moves the files.

>  PFC> Ugh.  There are a dozen simple ways of doing this. [...]  The point
>  PFC> is, though, that this has absolutely *nothing* to do with HURD, or
>  PFC> any other operating system.  The program used to delete files is just
>  PFC> that, a program.  It's a user application.

That was what I meant.  A user program.  Running in parallel with a
normal rm.  This is what I want to see.  I agree to some extent that
it has nothing to do with HURD, however, the rm problem is a definite
failing in the UNIX user interface.  If people are making mistakes
which are damaging then something is wrong.  However, I hate the idea
of confirmation (the most horrible thing I encounter is people with rm
aliased to rm -i.. yeuchh, If I say rm *, I mean rm * not "ask me
painfully and slowly over 3 hours if I want to delete
files".. normally).  The `trash' idea allows people to have
flexibility in what they mean..  And allows them to move back to
normal unix, without having got into bad habits.  For this reason I
think it's a neat solution to the problem.

Hurd is a new operating system, and is an(other) attempt to get
the enviroment right.  I think that for this reason, it's worth looking
for a better way of dealing with file deletion.  For this reason it's
worth looking at alternative solutions. Such as.. 

>Not entirely.  This assumes that the only time one deletes a file is from
>the command-line using the standard 'rm'.  This is simply not the case; I
>almost never use this command, as I do most file maintenance from within
>Emacs, which I assume is using unlink(2).  There are a great many other
>programs that use unlink as well.  In order to implement this new rm
>correctly, then, one needs to be able to modify the functionality of unlink,
>in all situations, so that no deletions seep through the cracks.  This kind
>of modification is most definitely an OS issue, and I would be impressed by
>a system in which this was possible at a user level without recompiled libc.
>

Which sounds nice, but has problems.  Some programs rapidly create
large numbers of temporary files.  As long as they do this in /tmp or
somewhere where unlink is told to just trash files from, this is okay,
but otherwise it could cause problems.  Also, there are lots of
different ways to lose files (cue...big display of ignorance).  For
example, if you open a file O_TRUNC from open(2) then all of the
contents disappear.  For example cat > fred where you meant cat >>
fred.  Although it's possible to explicitly protect against this (at
least for Linx/Ext2fs) by making files append only, it still leads to
people losing files where they didn't mean to.  There is no call to
unlink from open (I hope...).

Once you have begun to protect against all of the ways of losing files
you will have managed to generate huge amounts of deletion data.  I
think that controlling all of that is going to be too hard to manage.
It's certainly worth trying something like this idea to see if
something reasonable can be made to work.

Maybe we need a new 'trash' system call (system call is used in a lose
sense here... not part of the kernel e.g.).  This can be used as unlink
to compile programs for which it is suitable.  Programs which do too
much creation and deletion could be compiled with 'unlink' and new
programs could be compiled using both as appropriate.

		<http://www.ed.ac.uk/~p91152/biography.html>
Edinburgh Climbing Info Maintainer: <http://www.ed.ac.uk/~p91152/climbing/>
Linux/Unix clone@ftp://src.doc.ic.ac.uk/packages/linux/sunsite.unc-mirror/docs/