This dd cleanup has turned into a "rewrite and port over" sort of thing, so it's not quite the same incremental series of patches as a lot of previous cleanups.
I got summary() in (using the new clock_gettime() stuff since the milisecond time querying is apparently deprecated now), and hooked up the signal handling (with SA_RESTART for SIGUSR1 because although Linux no longer gives us length 0 reads with EINTR from SIGSTOP/SIGCONT, I suspect we _can_ get them from signal handlers we install unless we request the restart). Then I started doing seek and skip, and that has sharp edges in what posix says. I'm trying to follow posix closely enough that I at least document and justify all my deviations from it, and according to posix if lseek doesn't work you read the rest of the file that's there and write zero padding. In the case of an output file, you may have to read past all the existing data _and_ write zeroes to extend the file before the normal dd can commence. I _think_ that lseek(SEEK_SET) will return error and not move the file pointer, or return the position you asked for, and not return some _OTHER_ position (such as the end of the file if you seek past the end on a filesystem that doesn't support sparse). But I need to confirm/test this. What busybox does is support the fallback to reading past data for input, but for output it's lseek or nothing with no fallback to skipping what's there and padding the output manually. Which I object to because it's not _consistent_: if you're gonna do one... In linux, the input/output can be a pipe (no seek at all) or a file (seek and sparse). I should also test with char and block devices; block is seekable but not extensible so we can test some error paths. But there are also some fun questions about "what if the file is on a vfat filesystem, does that support sparse files?" To which the answer is "I dunno, let's find out"... (What I'm working on is a design where lseek will zero out seek= or skip= if successful, otherwise the main loop will handle it. Avoiding duplicate code while still handling all the correct corner cases. But I'll have to continue in the morning because I'm falling asleep right now...) Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net