Trash, Delete, Shred

[Luis Pedro Coelho]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Saturday 28 June 2003 13:31, David Hugh-Jones a écrit :
> On Sat, 2003-06-28 at 09:28, Luis Pedro Coelho wrote:
> > Please, don't do this. Sometimes I want to delete, sometimes I want to
> > move to trash.s
>
> Can I ask what the underlying need is?
>
> For remote files, you don't always want to move them into your trash -
> e.g. a 1G file over a slow connection. _Mostly_ I would think people
> want to delete remote files. Partly for connection reasons, partly
> because a file in your trash that was once "on some host somewhere" has
> probably lost all context that would explain where to put it back.

> What about "delete" vs "move to trash" on local filesystems? What makes
> you sometimes want to delete something rather than move it to the trash
> for deletion later? I'm not being rhetorical.

95 % of the time i want to "move to trash". It just allows me to trash stuff 
without thinking twice about it since there is an "undo".
However, ever so often, I want to really delete them. I want to really delete 
an iso image I downloaded after having burned it to CD, for example. In a 
nutshell, I rather just delete space-consuming things I know I can get again 
(downloaded stuff, saved email attachments - why keep one copy on disk and 
another in the mail?).

So, I do use both options.

I was working last month on a project for college. For license reasons, I had 
to develop it in a specific computer, but I could access through SSH. 
Therefore, I just connected my laptop to the school network, ssh'd in and 
used fish to transfer files. I kept feeling the need to "move to trash" 
fished files. I just feel safer moving to trash. The connection was very 
fast, so I don't think it makes almost any difference compared with moving to 
trash across partitions.

Of course, it really does depend. On another, slower, connection, I would 
probably just delete the files. 
I just say we shouldn't assume remote == slow/no-bandwidth. It sometimes is, 
it sometimes isn't.

> Hmm.
>
> I hate adding configuration options, but:
>
> (o) Move all files to trash
> ( ) Move local files to trash, delete remote files
> ( ) Delete all files
>
> [x] Ask for confirmation

I think local and remote files should be handled as similiarly as possible.

Of course, realistically local files != remote files. But that separation is 
not hard & fast. A kernel mounted samba share is a local file, but the same 
share accessed thru smb:/ is not.

> > Overall, I must say I am against it. My suggestion: get rid of "Shred."
> > It's a broken concept and very few people understand what it means. And
> > those will probably understand it doesn't give you any reassurances.
> > It's a bad idea.
>
> If shred doesn't actually guarantee that your files are killed, then we
> should ditch it - but I didn't know that. I would be fairly keen to get
> rid of shred, I think it is more a job for a specialized app than a
> general file manager.

I believe Shred is impossible to correctly implement. On a normal filesystem, 
on normal usage, it should work, but it is not garanteed to and in certain 
situations it will not work.

Besides, I agree that it doesn't really belong in a general file manager. 
I would argue it belongs in the kernel, actually.

Regards,
- -- 
Luis Pedro Coelho

On user interfaces and languages, see:
http://luispedro.journalspace.com/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+/W/3GpBAvyRwXdgRAkvjAJ4uEM0mRZq+ARYMu+CuSDzeEK1N/gCfcA0E
rww7nc0Vi7JsKZBCUrFzID8=
=OdCw
-----END PGP SIGNATURE-----