[Bug 10191] dd with conv=fsync after dba0dc1999bb1e8bfe64607e2a9385cda361fcb7 no longer works as expected

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=10191

--- Comment #3 from Neil MacLeod <busybox at nmacleod.com> ---
Hi Denys.

Yes, after opening this issue I did take a look at GNU dd and saw that it does
fsync just the once, so I guess that Busybox now matches the behaviour of GNU
dd.

Unfortunately the status=progress output doesn't appear to be anything we can
easily use/parse and reformat into a simplified version for the user. What we
need - and have been using successfully up to this point - is a simple 0-100%
progress indicator, and one that accurately reflects what is synced to the file
system (which would be impossible with only a single fsync).

If necessary we'll just continue to revert this change, although I'd argue that
changing the behaviour of dd like this (and at this stage for what seems like a
marginal benefit) may not be the best idea regardless of how GNU dd behaves - I
wouldn't be surprised if this catches out other embedded installations that
expect the "old" dd fsync behaviour.

It's pretty easy to simulate the GNU dd without this fsync change (dd && sync),
but impossible to recreate the old Busybox dd behaviour that fsynced multiple
times during the transfer.

Would it be possible to keep the old fsync behaviour as the default, but enable
this new one-fsync behaviour via a build option? That might be the safest/most
compatible solution?

-- 
You are receiving this mail because:
You are on the CC list for the bug.