[Thunar-dev] overwriting files and the trash

[Erlend Davidson]

On 2 Aug 2006, at 17:37, Rodrigo Coacci wrote:

>
>
> On 8/2/06, Erlend Davidson <E.R.M.Davidson at sms.ed.ac.uk> wrote:
> Samuel Verstraete wrote:
> > Hi Benny,
> >
> > 2 small issues...
> >
> > First: I was wondering if the expected behaviour of overwriting  
> files
> > would be to store the "overwritten" file in the trash... i certainly
> > was expecting this but it might be just me ;)
> >
> You mean if you edit a file called myfile the old (unedited)  
> version is
> stored as myfile~... but you're saying you want the myfile~ to be  
> in the
> trash?
>
> I guess it isn't what he means, even because any FM could be able  
> to do that... It should be resposability of the editor (or whatever  
> app you are using) to do it.
> I guess what he meant was when you copy/move a file over another  
> (using Thunar), effectively overwriting it, it could get the to-be- 
> overwritten file and put it in trash before overwriting it.
Ah now I see what he means - I like it, it's an interesting idea.   
Overwriting a file is similar to deleting the file and putting a file  
in its place with the same filename... except if you did this the  
file you deleted would be in the trash for you.  It could be an option:
=====
Are you sure you want to overwrite file.conf?
Overwrite     Overwrite and store old version in trash     Cancel
=====

> But I don't really think this is reasonable... And for big files,  
> could create a big performance issue, not to tell about disk space....
>
That's going to be a problem for the trash system in general.  If you  
give people an option (like above) this wouldn't be an issue (they  
can just opt out of putting it in the trash if the file is too big).

What about standards though?  I don't *think* this breaks any  
standards because overwriting is comparable to deleting then writing   
again (as mentioned above).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/thunar-dev/attachments/20060802/98fbf0c6/attachment.html>