Bug 143617 - cancel button in file exists dialog doesn't work
Summary: cancel button in file exists dialog doesn't work
Status: RESOLVED FIXED
Alias: None
Product: kftpgrabber
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Jernej Kos
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-30 03:27 UTC by IgnorantGuru
Modified: 2007-04-02 18:28 UTC (History)
0 users

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 IgnorantGuru 2007-03-30 03:27:54 UTC
Version:           0.8.0 (using KDE KDE 3.5.5)
Installed from:    Ubuntu Packages
Compiler:          http://karl.glatz.biz/oss/kftpgrabber_0.8.0-0ubuntu1~edgy_i386.deb 
OS:                Linux

Situation:  I am uploading a folder containing multiple folders and files.  The folder already exists on the site but I want to correct any incomplete or missing files.

If a file exists and the Skip/Overwrite/.../Cancel dialog appears, pressing the Cancel button does not cancel the multiple upload - it seems to have the same effect as pressing Skip.  My expectation is that it would cancel all uploads.  The only way to accomplish this is to close KFTPGrabber and restart it.

Related to the same situation, I'll include a wish...  KFTPGrabber seems to fetch the directory listing after every single upload attempt, causing it to take a VERY long time to upload multiple files, especially if they already exist, or if there are a lot of small files.  It would be far more efficient to read the directory listing once per folder before beginning, and once per folder when done.  This behavior makes KFTPGrabber far slower than other clients in this situation (a 5 minute task can instead take hours).
Comment 1 Jernej Kos 2007-04-02 13:09:50 UTC
The first mentioned problem will be fixed ASAP - pressing cancel will now abort any currently running transfers.

Can you elaborate on the second problem ? If I try to upload some files, KFTPgrabber doesn't fetch the directory listing after every uploaded file:

[13:04:38] *** Uploading file 'calamar_031.zip'...
[13:04:38] SIZE /test/cache/calamar_031.zip
[13:04:38] 550 /test/cache/calamar_031.zip: No such file or directory
[13:04:38] TYPE I
[13:04:38] 200 Type set to I
[13:04:38] EPSV
[13:04:38] 229 Entering Extended Passive Mode (|||2679|)
[13:04:38] *** Establishing data connection with 192.168.0.1:2679...
[13:04:38] *** Data connection established.
[13:04:38] STOR calamar_031.zip
[13:04:38] 150 Opening BINARY mode data connection for calamar_031.zip
[13:04:39] 226 Transfer complete.
[13:04:39] *** Transfer completed.
[13:04:39] *** Uploading file 'ls-lR.gz'...
[13:04:39] SIZE /test/cache/ls-lR.gz
[13:04:39] 550 /test/cache/ls-lR.gz: No such file or directory
[13:04:39] TYPE I
[13:04:39] 200 Type set to I
[13:04:39] EPSV
[13:04:39] 229 Entering Extended Passive Mode (|||1516|)
[13:04:39] *** Establishing data connection with 192.168.0.1:1516...
[13:04:39] *** Data connection established.
[13:04:39] STOR ls-lR.gz
[13:04:39] 150 Opening BINARY mode data connection for ls-lR.gz
[13:04:41] 226 Transfer complete.
[13:04:41] *** Transfer completed.

How can I reproduce the caching problem you mention and attach some information from the log ?
Comment 2 Jernej Kos 2007-04-02 13:15:20 UTC
Oh and please open another bug report for the second problem and post any relevant information mentioned in comment #1 there.
Comment 3 Jernej Kos 2007-04-02 13:16:33 UTC
SVN commit 649231 by kostko:

Pressing "cancel" on the "file already exists" dialog now aborts the transfer.

BUG: 143617

 M  +13 -0     engine/thread.cpp  
 M  +1 -1      engine/thread.h  
 M  +11 -2     kftpqueue.cpp  
 M  +2 -1      kftptransferfile.cpp  


--- trunk/extragear/network/kftpgrabber/src/engine/thread.cpp #649230:649231
@@ -185,6 +185,19 @@
   m_wakeUpPending = true;
 }
 
+void Thread::abort()
+{
+  // Clear any pending wakeup events
+  if (m_wakeUpPending) {
+    QMutexLocker locker(&m_wakeupMutex);
+
+    m_wakeupEvent = 0;
+    m_wakeUpPending = false;
+  }
+  
+  m_socket->protoAbort();
+}
+
 void Thread::event(Event::Type type, QValueList<EventParameter> params)
 {
   if (m_eventHandler) {
--- trunk/extragear/network/kftpgrabber/src/engine/thread.h #649230:649231
@@ -92,7 +92,7 @@
      */
     void wakeup(WakeupEvent *event);
     
-    void abort() { m_socket->protoAbort(); }
+    void abort();
     void connect(const KURL &url);
     void disconnect();
     void list(const KURL &url);
--- trunk/extragear/network/kftpgrabber/src/kftpqueue.cpp #649230:649231
@@ -691,9 +691,18 @@
           event->newFileName = newDestPath;
           break;
         }
+        case KIO::R_CANCEL: {
+          // Abort queue processing
+          Manager::self()->abort();
+          transfer->parentObject()->abort();
+          
+          // An event is not required, since we will not be recalling the process
+          delete event;
+          event = 0;
+          break;
+        }
         case KIO::R_AUTO_SKIP: Manager::self()->setDefaultFileExistsAction(FE_SKIP_ACT);
-        case KIO::R_SKIP:
-        case KIO::R_CANCEL: event->action = FileExistsWakeupEvent::Skip; break;
+        case KIO::R_SKIP: event->action = FileExistsWakeupEvent::Skip; break;
         case KIO::R_RESUME_ALL: Manager::self()->setDefaultFileExistsAction(FE_RESUME_ACT);
         case KIO::R_RESUME: event->action = FileExistsWakeupEvent::Resume; break;
         case KIO::R_OVERWRITE_ALL: Manager::self()->setDefaultFileExistsAction(FE_OVERWRITE_ACT);
--- trunk/extragear/network/kftpgrabber/src/kftptransferfile.cpp #649230:649231
@@ -258,7 +258,8 @@
       DirectoryListing list = event->getParameter(0).asDirectoryListing();
       FileExistsWakeupEvent *event = Manager::fileExistsAction(this, list.list());
       
-      remoteConnection()->getClient()->wakeup(event);
+      if (event)
+        remoteConnection()->getClient()->wakeup(event);
       break;
     }
     default: break;
Comment 4 IgnorantGuru 2007-04-02 18:28:36 UTC
Thanks for the quick response.  I have posted the second problem here...
http://bugs.kde.org/show_bug.cgi?id=143744