/usr/bin/tar creates invalid lib file

Konstantin Belousov kostikbel at gmail.com
Sun Mar 25 23:37:19 UTC 2012


On Sun, Mar 25, 2012 at 04:32:53PM -0700, Tim Kientzle wrote:
> 
> On Mar 25, 2012, at 2:43 PM, Gleb Kurtsou wrote:
> 
> > I experience a related issue. lseek(SEEK_HOLE) error checks are too
> > strict. Files are not added to archive if lseek(SEEK_HOLE) fails.
> > Ignoring lseek(SEEK_HOLE) at least in ENOTTY case would be preferable.
> 
> Just noticed that lseek(1) doesn't document ENOTTY as
> a valid response code.
> 
> Should it?
It seems that man page contradicts the actual lseek(2) behaviour.
Man page states that there shall be a virtual hole after file end,
even on the filesystems not supporting hole reports.

Is there some regression test set for SEEK_HOLE/SEEK_DATA ?
I found nothing in our tests, in particular, pjdfstest does
not mention the options.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20120325/c6cb9667/attachment.pgp


More information about the freebsd-current mailing list