On 02/27/2012 06:06 PM, Pádraig Brady wrote: > On 02/27/2012 05:14 PM, Paul Eggert wrote: >> On 02/27/2012 08:10 AM, Pádraig Brady wrote: >>> I'm also thinking I should warn once when >>> the new lseek fails, but only after the fall back >>> write() succeeds. >> >> I wouldn't bother. Either diagnostic should suffice, >> and warning about the lseek would slow the app down >> a bit and make it more complicated. > > Yep, I meant defer to the write() diagnostic. > > What I was wondering was whether to warn about > the case where the seek fails but the write succeeds like here: > > dd conv=sparse bs=1 count=10 | ... > > I'll leave it as advisory for now, and not have > a warning for the above case.
Another adjustment I'll need to make is how to handle existing regular files with conv=trunc. I.E. seeking over existing possible non NUL data. It's too dangerous/inconsistent to do this for files I think. With devices we can support auto allocating virtual devices as mentioned elsewhere in the thread. We could do any of these for existing files with conv=sparse,notrunc 1. disallow conv=sparse,notrunc 2. ignore sparse (with warning) 3. allow sparse in the additional part of output file 4. detect holes in output file and maintain. I'm leaning towards 2 as that will allow us to change to 3 or 4 if deemed necessary in future. cheers, Pádraig.
