On Fri, Jan 24, 2014 at 03:30:20AM +0000, Pádraig Brady wrote: > On 01/24/2014 03:12 AM, Rodrigo Campos wrote: > > On Fri, Jan 24, 2014 at 02:59:41AM +0000, Pádraig Brady wrote: > >> On 01/24/2014 02:41 AM, Rodrigo Campos wrote: > >>> On Fri, Jan 24, 2014 at 01:07:21AM +0000, Pádraig Brady wrote: > >>>> On 01/24/2014 12:47 AM, Bernhard Voelker wrote: > >>>>> Inspired by a recent post on util-linux ML [1], talking about turning > >>>>> a file into a sparse file in-place, i.e. not using a 2-step approach > >>>>> like `cp --sparse file file2 && mv file2 file`), I thought, hey, don't > >>>>> we have this in coreutils already? > >>>> > > > > But, a question about policy: is it okay to implement linux-only extensions > > here ? > > If the current system doesn't support in place sparsify, > then be could document that limitation along the > same lines as the conv=notrunc case above.
Sorry, not sure I follow you here. If we have the same documentation, the conv=notrunc case never says anything platform nor filesystem specific. And that is a big difference, IMHO. And, also, truncate() is a quite common function. I mean, is there any linux specific extension to a tool in coreutils ? (optimization underneath, using linux-only features is totally different IMHO). But it's just a matter of policy. Do you know what the policy is ? > If one wanted more portable guarantees about sparsifying a file, > then it would be best to use a temporary file anyway. ¿? What do you mean by this ? > If there are other methods to punch a hole in a file > on other systems, they can be added as an option to coreutils > without changing the interface. AFAIK, there aren't. And, as I said, is not linux specific only, it also is fs specific. If I have to guess, this flag is like other useful flags linux adds and most other platforms don't. So you are exposing a feature here, that will only will work on linux with certain filesystems. Probably there is a policy already esablished for this ? (I mean, if it's ok or not) Thanks, Rodrigo
