[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