Le 21/07/2014 à 12:28, intrig...@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
