[Pkg-privacy-commits] [libgsecuredelete] 50/168: Fix for progress of Gsd.DeleteOperation

Ulrike Uhlig u-guest at moszumanska.debian.org
Thu Jul 7 20:06:39 UTC 2016


This is an automated email from the git hooks/post-receive script.

u-guest pushed a commit to branch master
in repository libgsecuredelete.

commit 19d01239f56cbb9e9a0ba8d6501213998d4fb5c7
Author: Colomban Wendling <ban at herbesfolles.org>
Date:   Tue Feb 23 03:15:49 2010 +0100

    Fix for progress of Gsd.DeleteOperation
    
    Now we walks the directories/files we shall delete to determine how
    much they actually are. See comment on top of count_files() for
    details.
    Reverts changes from c69fd4f.
---
 TODO                                | 26 ------------------
 gsecuredelete/delete-operation.vala | 53 ++++++++++++++++++++++++-------------
 2 files changed, 35 insertions(+), 44 deletions(-)

diff --git a/TODO b/TODO
index 3e48d7d..4b4eebe 100644
--- a/TODO
+++ b/TODO
@@ -10,32 +10,6 @@ See result of `rgrep FIXME gsecuredelete` and `rgrep TODO gsecuredelete` too.
 
 
 FIXMEs:
-* Fix progress behavior when deleting folder(s):
-  srm reports the progression for each files in the directory and not for the
-  directory itself. The problem is obviously that then the progress overflows
-  the percent (100*(n_files_in_dir -1)) since our progress computation method is
-  (total_current_srm_progress / (n_input_files * n_passes_per_file)).
-  I see 3 "fixes" with pro and cons:
-    1) Just don't report over 100% (clamp).
-      pros:
-        * Easy.
-      cons:
-        * The progression is obviously wrong, stuck to 100% after the first
-          file.
-    2) Report (n % 1.0), so overflow are something like restarts.
-       [This is now the current behavior]
-      pros:
-        * Should be quite easy;
-        * Better than 1).
-      cons:
-        * Not so exact, and can be quite discouraging to the user too.
-    3) Count files in the directory.
-      pros:
-        * The progress is exact.
-      cons:
-        * This is resources-greedy;
-        * Perhaps a little overkill.
-
 + Better design for the arguments, allowing subclasses not to need to add
   parent's supported arguments themselves.
 
diff --git a/gsecuredelete/delete-operation.vala b/gsecuredelete/delete-operation.vala
index 6599552..0136416 100644
--- a/gsecuredelete/delete-operation.vala
+++ b/gsecuredelete/delete-operation.vala
@@ -83,6 +83,40 @@ namespace Gsd
       }
     }
     
+    /* Counts files (non-directories to be exact), starting from @path.
+     * Used to get the actual count of files we shall delete (and then the
+     * actual final progress) because srm reports the progress for each and
+     * every file it deletes, even if they was inside a directory we given.
+     * Note that there is no progress for directories at all, then skip them;
+     * just keep the files they holds.
+     * 
+     * Even if somewhat overkill, it should not have (a too big) impact on speed
+     * since srm shall walk the directories anyway then we might have cached
+     * them already, and the srm work is slow anyway.
+     * Then keep goin', we're happy with that. */
+    private uint count_files (string path)
+    {
+      uint n_files = 0;
+      
+      if (FileUtils.test (path, FileTest.IS_DIR)) {
+        try {
+          var     dir = Dir.open (path);
+          string  name;
+          
+          while ((name = dir.read_name ()) != null) {
+            n_files += count_files (Path.build_filename (path, name, null));
+          }
+        } catch (FileError e) {
+          /* silently fail, doesn't matter. we just guess anyway */
+          /*warning ("** %s\n", e.message);*/
+        }
+      } else {
+        n_files++;
+      }
+      
+      return n_files;
+    }
+    
     /* builds the command's argument vector */
     protected override List<string> build_args ()
       throws AsyncOperationError
@@ -96,7 +130,7 @@ namespace Gsd
       this.n_files = 0;
       foreach (unowned string path in this._paths) {
         args.append (path);
-        this.n_files++;
+        this.n_files += this.count_files (path);
       }
       
       if (this.n_files == 0) {
@@ -116,22 +150,5 @@ namespace Gsd
     {
       return base.get_max_progress () * this.n_files;
     }
-    
-    /* This overrides the parent one not to overflow if we delete a directory
-     * and we don't know the number of files in it. This is not the most perfect
-     * fix for the user point of view, but it is quite correct and easy. See
-     * FIXME in TODO file for details. */
-    protected override uint get_progress ()
-    {
-      uint progress = base.get_progress ();
-      
-      /* don't overflow n_passes */
-      if ((this.passes + progress) > this.n_passes) {
-        progress = (this.passes + progress) % this.n_passes;
-        this.passes = 0;
-      }
-      
-      return progress;
-    }
   }
 }

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-privacy/packages/libgsecuredelete.git



More information about the Pkg-privacy-commits mailing list