Re: [Bug-tar] [PATCH] Re: Detection of sparse files is broken on btrfs

Pavel Raiskup wrote: > On Tuesday, January 9, 2018 8:59:06 AM CET Paul Eggert wrote: > > Pavel Raiskup wrote: > > > So what about special casing that filesystem, where we can lseek() for > > > holes anyway? > > > > If we can lseek for holes, then why not just do that? > >

Re: [Bug-tar] [PATCH] Re: Detection of sparse files is broken on btrfs

Paul Eggert wrote: > If we can lseek for holes, then why not just do that? We shouldn't need > special-case code for btrfs per se. Any filesystem where we can lseek for > holes > should take advantage of that optimization. This is what star uses since 13 years ;-) Jörg

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

"Austin S. Hemmelgarn" <ahferro...@gmail.com> wrote: > On 2016-07-06 11:22, Joerg Schilling wrote: > > "Austin S. Hemmelgarn" <ahferro...@gmail.com> wrote: > > > >>> It should be obvious that a file that offers content also has all

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

"Austin S. Hemmelgarn" wrote: > > It should be obvious that a file that offers content also has allocated > > blocks. > What you mean then is that POSIX _implies_ that this is the case, but > does not say whether or not it is required. There are all kinds of >

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

Paul Eggert <egg...@cs.ucla.edu> wrote: > On 07/06/2016 04:53 PM, Joerg Schilling wrote: > > Antonio Diaz Diaz<anto...@gnu.org> wrote: > > > >> >Joerg Schilling wrote: > >>> > >POSIX requires st_blocks to be != 0 in case that the fil

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

Antonio Diaz Diaz <anto...@gnu.org> wrote: > Joerg Schilling wrote: > > POSIX requires st_blocks to be != 0 in case that the file contains data. > > Please, could you provide a reference? I can't find such requirement at > http://pubs.opengroup.org/onlinepubs/9699919799/

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

"Austin S. Hemmelgarn" wrote: > > A broken filesystem is a broken filesystem. > > > > If you try to change gtar to work around a specific problem, it may fail in > > other situations. > The problem with this is that tar is assuming things that are not > guaranteed to be

Re: [Bug-tar] stat() on btrfs reports the st_blocks with delay (data loss in archivers)

Andreas Dilger wrote: > I think in addition to fixing btrfs (because it needs to work with existing > tar/rsync/etc. tools) it makes sense to *also* fix the heuristics of tar > to handle this situation more robustly. One option is if st_blocks == 0 then > tar should also