On Friday 05 January 2001 02:45 balex@www.com wrote:
> Package: unknown
> Version: 2.0
> Severity: wishlist
> Installed from: redhat rpms
>
> The trash bin has to act only as a place to recover
> accidentally deleted files.
> We not need all the funcions of a simple directory.
> So why don't you threat the trash bin in a more efficiet
> way such as gzipping files when inserted mantaining a
> catalog which describes where was the files deleted ? (You
> can do this because we don't need to view/launch files in
> trash bin).

Simply moving a file to the trash is more efficient (cpu-wise) than zipping 
it first. The trashcan can certainly use some enhancements though... 
volunteers are welcome :-)

Cheers
Waldo
-- 
bastian@kde.org | SuSE Labs KDE Developer | bastian@suse.com

I thinking about making a KIO-slave which should make the trashcan work as it
should.  
Is this worked on currently ? 

Subject: Re:  trash bin

On Wednesday 26 March 2003 22:19, you wrote:
> I thinking about making a KIO-slave which should make the trashcan work as it should.  
Yes, we are many to have had the same thought ;)

> Is this worked on currently ?
No. Feel free to go ahead - and make sure to commit early, so that
others can help, and know you're working on it.
(http://developer.kde.org/documentation/other/developer-faq.html#q8 for getting
a cvs account)

What was also suggested was to use the same file format as Nautilus.
If you're interested maybe I can find some very old mails where we
discussed that (and the location of the trash folders to minimize "moving
to another partition", etc.)

kde-3.2-features.html says that lypanov is working on a trash kioslave 

Subject: Re:  trash bin

On Fri, Mar 28, 2003 at 01:52:20PM -0000, Stephan Binner wrote:
> kde-3.2-features.html says that lypanov is working on a trash kioslave

kind of, but it would be really nice if someone 
else could take the load off of me :)

Alex

*** Bug 58958 has been marked as a duplicate of this bug. ***

The trash in KDE is missing essential features for me.

1.I would really like KDE's trash to have the ability to restore files from the
context menu over the trash icon.
2. When the trash is opened I want to be able to restore a file or group of
selected files via the context menu as well as have the option to shred them.
3. In the context menu for the trash icon and when you click white space in the
trash file viewer there should be something called properties in which you can
adjust various settings like how big the trash can get before it auto deletes.
I'm thinking a slider that shows it as how big (%) out of all the space
available and as you move the slider there should be next to it a text field
that shows how much that would actually be in MB or GB depending on how many
available. This text box should be editable by the user in case he does not want
to use the slider.
5. There should also be in the properties dialog things such as a delete command
to bypass the move to trash command in the menu , icon settings(like a normal
icon) and much more such as when to clean out the trash ons chedule, like
everyday at 5 for example.
6. Shred command, isntead of just empty trash, it should also have shred files.
7. I often move files to trash and I've always wanted to move it to the panel
and it annoys me that I can not move the trash icon to the panel without losing
its trash features such as empty trash. I think this should work. 


Just some suggestions, unfortunately  do not know how to code. =(

Also, is anyone else having the following problem or is it just me:

I move  a file or gorup of files from one folder to the other and when I ress
undo in the original folder it says malformed URL, no matter where it comes from. 

*** Bug 59822 has been marked as a duplicate of this bug. ***

*** Bug 65676 has been marked as a duplicate of this bug. ***

Perhaps it would be a good idea, to develop a system wide trash system intead
doing a KDE only solution.

On Mac OS X every user has a Directory ~/.Trash which represents the trash can.

It should also be possible to move files to the trash via shell (using a new
command or shell script).

One prob is, that on Mac OS X and on KDE the trash cannot contain two files from
the same location:

* Create a file 'New text.txt' and move it to trash
* Create a file 'New text.txt' and move it to trash again

=> KDE complains that there is already such a file

So, the trash should be also usable via shell and automatically rename the file
in any way giving it an ID but showing the original name and location, also for
multiple files whith the same name and origin location.

One have to say, that it is made very good on Wintoys where all the pointed
issues are realized. No flaming please, just facts ;-) .

Subject: Re:  enchanements to trash bin: ioslave

> One have to say, that it is made very good on Wintoys where all the pointed
> issues are realized. No flaming please, just facts ;-) .
Which shell tools does Windows offer for trashing files? 

okay, i'll accept.... :(

;-)

Alex

*** Bug 47515 has been marked as a duplicate of this bug. ***

*** Bug 41882 has been marked as a duplicate of this bug. ***

*** Bug 70805 has been marked as a duplicate of this bug. ***

As stated above, a gzip/bzip/zip handler would be nice to minimize trahsed
files load on the filsystem. It could be configured so either it compresses the
files as they are dropped on the Trash or compress them on demand or compress
the files if the trash becomes bigger than X bytes.

Just my 2c

The Wastebin/Trash really needs a "restore" function... Right now, I have to
copy/cut/drag any files I accidently delete back to their original location,
which is a pain in the neck, especially if I don't remember where the file was
originally! 

Also, you should be able to open files in the Wastebin... If I think I want to
keep a file, but I am not sure from the name, I can't even tell what is is
until I take it out of the Wastebin. Not good.

Ditto to everything Alex R. said. Some very good ideas there...

I agree a kio slave or system wide trash is welcome (to allow restore,
managing, compression...) but what I miss is :

Why must we do the trash can "extract only" ?
Why musn't we able to view / open / preview files in the trash ?

If we aren't sure what a filename represent we must restore it in any place
(e.g. to desktop for quick), preview / open it and then re-move it to trash if
it isn't which we want to recover.

Problems :
- It's a pain !!! Not user friendly
- If we extract files anywhere and re-move them to trash, the eventual
"original location" field will become this anywhere folder (Desktop, in my
exemple) : not good. And if we choose restore it in the original location, we
must browse file system to be able to preview it...
- Preview in trash is powerfull : scannning a trash full of files would be
quick !

On Tuesday 16 March 2004 07:42, Sebastien wrote:
> Why musn't we able to view / open / preview files in the trash ?
> 
> If we aren't sure what a filename represent we must restore it in any place (e.g. to desktop for quick), preview / open it and then re-move it to trash if it isn't which we want to recover.
> 
> Problems :
> - It's a pain !!! Not user friendly

Because otherwise people will just click on a .kwd file in the trash, it opens
in KWord, and they work on it - without ever restoring the file to a real location.
Result: they'll work on the file for a while, but the next time the empty their trash,
they'll lose the document.

On 16 Mar 2004 16:28:41 -0000, David Faure <faure@kde.org> wrote:
> Because otherwise people will just click on a .kwd file in the trash, it 
> opens in KWord, and they work on it - without ever restoring the file to 
> a real location.
> Result: they'll work on the file for a while, but the next time the 
> empty their trash, they'll lose the document.

agreed. so, really both problems should be solved. i have no idea
how to do so. but the "proper" way would be to display a dialog saying
"if you want to open this it will be restored to its original
   location and that location will be edited, click here to open
   the restoration directory and here to continue loading the file"
or something to that effect but majorly simplified :P

mvg,
Alex

What's about making the files in the trash read-only (except for really
deleting them)? If you open a file from the trash, modify it and say "Save",
you'll get a "Save As" dialogue. 
Arne

> Because otherwise people will just click on a .kwd file in the trash, it
> opens in KWord, and they work on it - without ever restoring the file to
> a real location.

Hooooooo.... Okay !
I haven't thinked about that :)
But then, the "extract only" policy is a wrong / abitrary solution IMHO !!!
We just need to have those files [[[READ ONLY]]].
It's doable and what's expected ! It will happy everybody.
We then can show a dialog when user open them to say they cannot save modifications, or the application will do it (like Ark with read only archive :-/ ).

So, a kioslave trash can has another reason to exist : save rights + apply read only ; reload rights on restore.
Or if a folder is read only, are the files read only too ? I don't think...

Any remarq about this solution ?

Trash shouldn't allow the files to be opened directly _but_ should still allow
previews. If this is possible.

Also, about "gzip"ing files in order to save their location. Gzip is not
necessary, tar would do.  And that would not, as Waldo objected, cost CPU time.

I will implement an ioslave if nobody else wants to.

> Trash shouldn't allow the files to be opened directly _but_ should still allow previews. If this is possible.
Sure, the thumbnail module would work anyway.

> Also, about "gzip"ing files in order to save their location. Gzip is not necessary, tar would do. 
There's a contradiction here...

Anyway, IMHO saving their location (and date of deletion, mimetype, etc.) could
be done 
with text files (KSimpleConfig), using random-generated filenames.

See kfm-devel for the thread about this, and/or mail Aaron J. Seigo
<aseigo@kde.org>,
I think he has a copy of the discussion uploaded somewhere (there was 
a proposal long ago with the list of metadata to be saved for each file).

> And that would not, as Waldo objected, cost CPU time. 

Tar files are awful, you need to parse a lot before you get to the file you
want.
Gzipping individual files is OK, to save disk space, but tar is really a
killer.
And if files are gzip, that's another reason for storing the mimetype as
metadata,
to use the correct icon without having to gunzip the trashed file and check
its contents.

> I will implement an ioslave if nobody else wants to.

Sounds great :)
I suggest discussing the outline on kfm-devel first to make sure the design
is right and avoid having to redo it multiple times :)
My plan was to take a look at this with a few others in August at the KDE
conference,
but if you start it before, no problem, of course.

> Tar files are awful, you need to parse a lot before you get to the file 
> you want.

Do you mean "a lot" in terms of CPU usage or "a lot" in terms of code? If it is code, we already have libraries and an ioslave that can access tar. I don't know anything about the format of a tar, but I can't imagine it would be that complicated. 

Also, isn't there some some way you can append "garbage" data onto an end of a tar? If this is true, then the mimetypes could maybe be stored there. But that is just random musing.

Remember the three rules of design: simplicity, simplicity, simplicity.

On Tuesday 27 April 2004 02:40, Luke Sandell wrote:
> Do you mean "a lot" in terms of CPU usage or "a lot" in terms of code?
CPU usage.

> If it is code, we already have libraries and an ioslave that can access tar. 
I know, I wrote them :)

> I don't know anything about the format of a tar, but I can't imagine it would be that complicated.   
It's not complicated, it's braindead.
There's no index (like there is in a ZIP file). To get to the last file in a tar.gz, you have
to decompress the whole file from the start, until you finally skipped all the files 
and arrived at the last one.
ZIP is better in terms of partial reading (extracting one file out of the whole),
but both are really not efficient when it comes to adding a file to an existing archive
(at the moment you have to rewrite the whole archive into a new file!).

Why reinvent the filesystem, when you have a filesystem at hand?
Nothing says the contents of the trash has to be a single file, it's much simpler
(and much more efficient) if it's a directory.

> Remember the three rules of design: simplicity, simplicity, simplicity.
What's simpler than a plain text file, and using separate files for the trashed files? :)

On Tuesday 27 April 2004 03:58 am, David Faure wrote:
> There's no index (like there is in a ZIP file). To get to the last file in
> a tar.gz, you have to decompress the whole file from the start, until you
> finally skipped all the files and arrived at the last one.

Alright in that case it is really horrible.

I wonder if any filed format is useful. People work with real huge files today
(DVD-rips, ISO-Images etc.), so every delete and undelete will cause waiting
time.

So, I fear a directory based solution would be more performant. Deleting large
files on the same Volume where the trash bin resides can be performed in
milliseconds, and only files from other mount points have to be simply copied
(which will take some seconds), but it's not necessary this way to put the
deleted files through zip or tar, which will need CPU time, when deleting an
ISO image or a DVD rip really _lots_ of CPU time.

And what about the MS way: have a "recycle bin" hidden directory on every
non-read-only volume (like lost&found) and have GUI display items from all of
them transparently to user?

*** Bug 56737 has been marked as a duplicate of this bug. ***

*** Bug 22143 has been marked as a duplicate of this bug. ***

*** Bug 80380 has been marked as a duplicate of this bug. ***

Any chance of this getting into KDE 3.3? It is one of the areas where KDE lacks
most.

No chance for 3.3, the CVS is in feature freeze already.
But I plan to work on this at the KDE conference in August.

On Sunday 27 June 2004 20:20, Alex Radu wrote:
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
> http://bugs.kde.org/show_bug.cgi?id=18109
>
>
>
>
> ------- Additional Comments From exigentskies comcast net  2004-06-27 19:20
> ------- Any chance of this getting into KDE 3.3? It is one of the areas
> where KDE lacks most.

No volunteers for it.

*** Bug 86565 has been marked as a duplicate of this bug. ***

CVS HEAD now has the new kio_trash-based trash system, which I've been working
on since akademy.

It's now possible to delete multiple files with the same name, to preview
trashed files without being able to edit them. The new system has support for
restoring trashed files to their original location - I just need to add a menu
item for that, which I'll do right now.

Testers welcome - in particular, after updating all of kdelibs and kdebase,
restart KDE and check if your trash contents were correctly migrated, and the
new Trash icon works (and opens trash:/).

BTW the location and contents of the trash can are defined in an upcoming XDG
standard, so Nautilus and KDE (at least, maybe more later) can share the same
trash contents.

*** Bug 91656 has been marked as a duplicate of this bug. ***

David, please provide a command other than "dcop blah complicated file.txt" to
trash files on the command line. With the old trash can I could do this myself
and created the command "trash".

> David, please provide a command other than "dcop blah complicated file.txt" to trash files on the command line. 
> With the old trash can I could do this myself and created the command "trash". 

That's already available:
kfmclient move file:/tmp/log trash:/

Thank you!

This is a much welcome addition which all Linux desktops were lacking. 

Bug closed. Kdesktop is no more mantained.