progress
progress copied to clipboard
Xfennec
The target size is used in 'dd' while the progress should estimated by source.
When dd one device to another, size of the target is shown. This is ok, when source size > target size, but this situation is weird. Common usage is to dd equal devices or smaller to bigger. In last case, the amount of bytes (blocks) to copy is determined by source device size. But cv uses target device size thus giving wrong estimation.
The issue here is I'm not very keen to create specific path in the code for a command or another. You can think of many other particular cases where cv will display wrong / erroneous values.
So, should I keep cv as a general small and simple tool, or should I add a modular way to deal with specific commands...
Maybe I say now wrong and stupid thing, but it’s just idea from stranger. Can we display estimation based on source, not target (or both) for all / some process? This may be controlled dynamically in ncurses interface or via options in CLI.
Still an issue when you have to monitor both cases at the same time. It should be a "per command" setting.
That issue consist in what one of estimation still wrong? But IMO shortcut (and option) for manual choosing of estimation type is good.
Another problem i'd like to mention in this issue: You can specify the amount of data to dd, thus the estimation with either source or target value may be wrong.
Example: dd if=/dev/sda of=test.raw bs=1M count=1024
I think this command is pretty tricky and not so easy to implement nice and clean...
Came here to report that. When using cp to make a bootable usb stick (say cp foo.iso /dev/sdh), the target is larger than the source. I suggest adding the following flags: -s - use source file size instead of target file size for estimation; -S [num] - provide file size (should understand suffixes such as k, m, g, t as well as suffixes such as KiB, Ki, Ko, etc as well as upper/lower case variations. There has to be a library out there for that)
This is the only thing in my mind keeping this utility from being entirely perfect. Love the utility here, but I think that a solution such as what cheater suggested would be amazing.
I totally appreciate the goal of keeping the utility small and multifunctional, and I agree that its current behavior should be the default, but I think adding a command line arg like cheater has suggested could be the golden token here.
Are there any further thoughts on implementing something like this? I know this has been a little while since it was discussed.
