Bug 95654 - Second hard disk woken up while moving a file to trash
Summary: Second hard disk woken up while moving a file to trash
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: trash (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
: 102260 117392 136513 158903 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-12-22 13:52 UTC by Thomas McGuire
Modified: 2008-03-07 12:45 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas McGuire 2004-12-22 13:52:04 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

When I trash a file, my second harddisk is woken up, which causes long delays, noise and wastes energy.
My 2nd HD is only used as a backup partition and is thus very rarely used.
I don't know why trashing a file uses that disk, since the file I am moving to trash is not on that disk.

There is a trash folder at the root of my backup partition, but it is empty and, as already said, the file I trashed did not move there.
Comment 1 David Faure 2004-12-22 14:01:46 UTC
On Wednesday 22 December 2004 13:52, Thomas McGuire wrote:
> When I trash a file, my second harddisk is woken up, which causes long delays, noise and wastes energy.
> My 2nd HD is only used as a backup partition and is thus very rarely used.
> I don't know why trashing a file uses that disk, since the file I am moving to trash is not on that disk.

Hmm, that's because kio_trash looks at all available trash directories on startup.
It should be possible to do that a bit more "on demand" I guess.
Thanks for your kio_trash reports, I'll look into those.

Comment 2 David Faure 2005-01-18 12:36:43 UTC
CVS commit by faure: 

Provide stability in the trash IDs, so that restoring or asking
for properties works even kio_trash gets killed because idle.

A bit more caching of the trash dirs too, might help 95654 (can you re-test?)
Now only startup and listing trash:/ should scan for trash dirs on all disks.

CCBUG: 95654


  M +14 -5     trashimpl.cpp   1.32


--- kdebase/kioslave/trash/trashimpl.cpp  #1.31:1.32
@@ -500,4 +500,5 @@ void TrashImpl::emptyTrash()
 {
     kdDebug() << k_funcinfo << endl;
+    if ( !m_trashDirectoriesScanned )
     scanTrashDirectories();
     // For each known trash directory...
@@ -518,5 +519,8 @@ void TrashImpl::emptyTrash()
 TrashImpl::TrashedFileInfoList TrashImpl::list()
 {
+    // Here we scan for trash directories unconditionally. This allows
+    // noticing plugged-in [e.g. removeable] devices, or new mounts etc.
     scanTrashDirectories();
+
     TrashedFileInfoList lst;
     // For each known trash directory...
@@ -620,4 +624,5 @@ bool TrashImpl::isEmpty() const
 {
     // For each known trash directory...
+    if ( !m_trashDirectoriesScanned )
     scanTrashDirectories();
     TrashDirMap::const_iterator it = m_trashDirectories.begin();
@@ -684,4 +689,7 @@ int TrashImpl::findTrashDirectory( const
         return id;
     // new trash dir found, register it
+    // but we need stability in the trash IDs, so that restoring or asking
+    // for properties works even kio_trash gets killed because idle.
+#if 0
     kdDebug() << k_funcinfo << "found " << trashDir << endl;
     m_trashDirectories.insert( ++m_lastId, trashDir );
@@ -690,8 +698,9 @@ int TrashImpl::findTrashDirectory( const
     m_topDirectories.insert( m_lastId, mountPoint );
     return m_lastId;
+#endif
+    scanTrashDirectories();
+    return idForTrashDirectory( trashDir );
 }
 
-// Maybe we could cache the result of this method.
-// OTOH we would then fail to notice plugged-in removeable devices...
 void TrashImpl::scanTrashDirectories() const
 {
@@ -709,7 +718,7 @@ void TrashImpl::scanTrashDirectories() c
                 int trashId = idForTrashDirectory( trashDir );
                 if ( trashId == -1 ) {
-                    kdDebug() << k_funcinfo << "found " << trashDir << endl;
                     // new trash dir found, register it
                     m_trashDirectories.insert( ++m_lastId, trashDir );
+                    kdDebug() << k_funcinfo << "found " << trashDir << " gave it id " << m_lastId << endl;
                     if ( !topdir.endsWith( "/" ) )
                         topdir += '/';


Comment 3 Thomas McGuire 2005-01-23 10:23:14 UTC
On Tuesday 18 January 2005 11:36, David Faure wrote:
> A bit more caching of the trash dirs too, might help 95654 (can you
> re-test?)
Sorry, I can currently not re-test, my second hard disk does not work 
anymore. Please be patient until I've fixed the problem.

Comment 4 Thomas McGuire 2005-02-10 23:48:03 UTC
On Tuesday 18 January 2005 11:36, David Faure wrote:
> A bit more caching of the trash dirs too, might help 95654 (can you
> re-test?) Now only startup and listing trash:/ should scan for trash
> dirs on all disks.
I just tested with CVS HEAD 02/06/2005 and can not confirm this. My second 
hard disk is still woken up when I trash a file.

Comment 5 Thomas McGuire 2005-02-11 00:08:29 UTC
Sorry, the above comment is not entirely accurate.
The harddisk is always woken up when trashing a file. However, this is not the case if trash:/ has been visited before.

So my suggestion is that when trashing the first file, all caching actions which take place when visiting trash:/ in Konqueror are executed, too.

I very rarely visit trash:/, but I trash a lot of files.
Comment 6 David Faure 2005-03-23 14:15:20 UTC
*** Bug 102260 has been marked as a duplicate of this bug. ***
Comment 7 Dik Takken 2005-07-18 14:30:34 UTC
I also have this problem, on KDE 3.4.1. Trashing a file spins up my second harddisk that contains rarely used data.
Comment 8 Nicolas Goutte 2005-08-13 23:12:35 UTC
Still the case.
Comment 9 mauceri 2005-09-19 17:53:43 UTC
I have a similar problem. I have mounted the hard disk of my digital receiver on /mnt/dreambox. When moving a file to trash or emptying the trash bin wakes up the harddisk of my digital receiver.
Comment 10 Nicolas Goutte 2005-12-01 13:02:29 UTC
*** Bug 117392 has been marked as a duplicate of this bug. ***
Comment 11 Nicolas Goutte 2005-12-01 13:03:38 UTC
Bug 117392 was about the CD-ROM being activated, which is potentially slower than another harddisk.

Have a nice day!
Comment 12 Bram Schoenmakers 2006-11-01 22:35:06 UTC
Fixed in KDE trunk (ie KDE 4).
Comment 13 Bram Schoenmakers 2006-11-01 22:35:29 UTC
*** Bug 136513 has been marked as a duplicate of this bug. ***
Comment 14 David Faure 2008-03-07 12:45:58 UTC
*** Bug 158903 has been marked as a duplicate of this bug. ***