[Pkg-privacy-maintainers] Bug#755487: nautilus-wipe: Progress bar for "Wipe available disk space" is not fine-grained enough

[Colomban Wendling]

Le 21/07/2014 à 12:28, intrigeri at debian.org a écrit :
> […]
> 
> 1. ext2 filesystem on a USB flash drive, with 2GB free space
> 2. right click in Nautilus -> Wipe available disk space
> 3. go through the dialog, not changing the default options
> 4. the progress bar stays at 0% for a long while, then moves to 50%,
>    then to 100%
> 
> => users report that they are confused: it's unclear for them whether
> the wipe operation is really happening, or the entire process
> is stuck.
> 
> Potential solutions I can think of:
> 
> a) make the progress bar more fine-grained, if not too much work;

That would be very nice, but unfortunately I have no clever idea how to
do that without a lot of effort.  There are 2 distinct problems:

1. the underlying tools (srm and sfill) only report 1 step per pass
(e.g. default 2 pass will give us 2 progress steps)

2. we use a wrapper script because of sfill limitations (lack of support
for FS file size limits), and it's hard to get the progress from the
underlying tools for technical reasons (processing incomplete lines).

However, the wrapper script could possibly be improved in that regard
based on some heuristics.  The script works in 3 steps (under NW control
at least):

1. create a temporary directory
2. create huge file(s) with dd, trying to fill up the disk
3. run sfill (on the virtually full FS, so likely to only fill inodes)
4. run srm on the temporary directory

The script currently reports progress *after* steps 2 and 4.

However, it is based on the (probably erroneous) assumption that 2
things were gonna take time: steps 2 and 4.  However, it is very
possible that creating huge files with dd (out of /dev/zero) (step 2) is
orders of magnitude faster than running srm on them (step 4).
If we decide it is the case, it would be possible to only report direct
srm progress (and none at step 2).

But that wouldn't change much in the end as, as said above, srm itself
won't report any more progress than the step count, and the default is
2.  The only thing is that it might give more accurate timing between
the progress steps (or not, depending on what takes time).

> b) or, display additional information about what step in the process
>    is being performed (e.g. "Pass 1/2", or whatever better wording UX
>    folks will find), so that at least the user gets a hint that the
>    progress bar is not supposed to be more fine-grained than it is;
>    see e.g. "6.17.3. Indeterminate-progress indicator" in the
>    GNOME HIG;
> 
> c) worst case, use the thing that goes back'n'forth inside a widget
>    that looks like a progress bar: this should make the "UI is frozen,
>    is anything happening at all?" problem more or less go away.

Hum, what is the real difference between b) and c)?  "6.17.3.
Indeterminate-progress indicator" [1] is all about pulsating progress bars.

However, those same HIG say not to use pulsating progress bars unless
there's absolutely nothing more precise to display -- which here is not
exactly the case.

However yeah indeed, it's far from optimal.

I tried implementing showing some basic steps (but here we don't know
much either), see i.e.
http://download.tuxfamily.org/wipetools/misc/nw-progress.mkv


Another possible indicator that things aren't frozen, although I cannot
do it in NW's side, would be the theme itself animating it.  Some theme
do display a moving background in the progress bar, which suggests
something is happening although it's actually a white lie :)


Another (kind of stupid) idea could be to fake some progress based on
timing (extrapolating it, basically a "time remaining" thingie), but
this has several problems:

 * we need to know an initial step timing before we can extrapolate
anything.  As there is no way to know, the first step would either not
have fake progress, or arbitrary one.
 * it would rely on actual progress step all taking about the same
amount time.  This is not really the case for the free space wiping yet
(see above).

So in typical situation, at best we get no/arbitrary progress for half
the process, and nice one for the remaining (assuming first half takes
as long as second half).  In the worst case, we get totally incorrect
progress in the second half -- either way too slow (doesn't really get
off 0.5% until the end), or way too fast (reaches near 100% way too soon).


[1]
https://developer.gnome.org/hig-book/3.12/hig-book.html#indeterminate-progress