Re: Trash and hidden files

[Mike Nugent <mnugent goamerica net>]

I hate to keep pointing out problems, but...

Let's say this is a multi-user system.  A school prehaps.  The
filesystems all have quotas on them so no student downloads say the
entire gnome cvs tree.  It would be horrible to get messages such as
"Not enough space left to delete file."  It would be just as bad to have
this problem on a single user system where the filesystem fills. 
Obviously, these problems can be worked around, but let's keep such
things in mind when we do the coding.  Messages saying "Not enough room
to store file in trash.  Are you sure you want to delete this file
perminently?" would be better.  Other than that, I like the
/.gnome-trash/...  idea a lot.  It can be it's own filesystem and can
easily be backed up (or even nfs mounted to a NetApp or something) this
way.

--
Michael Nugent
mike@illuminatus.org


Loban Amaan Rahman wrote:
> 
> > But there's room for modification here: maybe each user gets a private
> > directory underneath the trash folder.  In fact, I think I like that
> > even better, especially if it's optional.  On multiuser systems, it's a
> > good security feature.  On single user systems, or systems where the
> > users all trust each other, the feature can be turned off.
> >
> > Or, maybe the trash folder maintains a duplicate of the main filesystem:
> > if I delete /home/tangent/docs/foobie.txt, it might be stored as
> > /.gnome-trash/home/tangent/docs/foobie.txt, with all the original
> > permissions along the path.  That's more work, but just as secure as the
> > original file was.
> 
> I think the last idea is the best of all. Many good things seem possible
> from it. It's okay security-wise, because the trashed filesystem will
> have the same permissions as the original. If a user recursively trashes
> directories, they can be restored perfectly. (Also, if a user wants to
> restore a recursively trashed directory into a path different from the
> original, it can be implemented without too much trouble). Plus, because
> each filesystem has it's own trashfolder, trashing a file consists of
> little more than just "moving" the files into the trash-folder, creating
> the directory structure as need -- a pretty fast operation because no
> files are traveling across filesystems.
> 
> I'd like to add one thing - this applies both to regular deleting and
> trashing. When recursively trashing directories (using rm -R and gmc),
> symlinks are by default deleted but the stuff they point to are not
> touched. GMC and/or it's successor should have an option (in it's
> preferences) on what to do when it encounters a symlink on deleting/
> trashing/moving/copying :
>         (1) Just copy the symlink (what happens if it's a relative
>                 symlink that refers to something not touched)
>         (2) Enter into the referred path and continue deleting/trashing/
>                 etc.
>         (3) Prompt for a user choice.
> 
> |       LOBAN AMAAN RAHMAN  <-- anagram of -->  AHA! AN ABNORMAL MAN!      |
> |   Snail: MSC #763, Caltech, Pasadena, CA 91126, USA. ** 1-626-395-1407   |
> |     Wired: loban@earthling.net, loban@caltech.edu, http://i.am/loban     |
> | (Do 'finger loban@ugcs.caltech.edu' for my PGP public key and more info) |
> 
> --
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with
>                        "unsubscribe" as the Subject.