[debbugs-tracker] bug#22931: closed (tests/split/filter.sh fails on an XFS file system)

[GNU bug Tracking System]

Your message dated Tue, 8 Mar 2016 13:01:08 -0800
with message-id <address@hidden>
and subject line Re: bug#22931: tests/split/filter.sh fails on an XFS file 
system
has caused the debbugs.gnu.org bug report #22931,
regarding tests/split/filter.sh fails on an XFS file system
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
22931: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22931
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: tests/split/filter.sh fails on an XFS file system Date: Sun, 6 Mar 2016 19:36:13 -0800

The split/filter.sh test would fail like this:

  $ make check TESTS=tests/split/filter.sh VERBOSE=yes SUBDIRS=.
  + truncate -s9223372036854775807 zero.in
  + timeout 10 sh -c 'split --filter="head -c1 >/dev/null" -n 1 zero.in'
  split: zero.in: cannot determine file size: Value too large for
defined data type

That value is 2^63-1 (nearly 8 exabytes), and split.c
explicitly handles a file of that size, because that is
the size reported for /dev/zero on GNU/Hurd systems,
according to the comment.

This fixes the test not to trigger that work-around:
[I'll update the commit log with the issue URL as soon as it's assigned]

0001-tests-avoid-false-failure-of-split-filter.sh-on-XFS.patch
Description: Text Data

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#22931: tests/split/filter.sh fails on an XFS file system
>
>
>
>
> Date: 
>
> Tue, 8 Mar 2016 13:01:08 -0800
>
>
>
>
> On Sun, Mar 6, 2016 at 7:36 PM, Jim Meyering <address@hidden> wrote:
> > The split/filter.sh test would fail like this:
> >
> >   $ make check TESTS=tests/split/filter.sh VERBOSE=yes SUBDIRS=.
> >   + truncate -s9223372036854775807 zero.in
> >   + timeout 10 sh -c 'split --filter="head -c1 >/dev/null" -n 1 zero.in'
> >   split: zero.in: cannot determine file size: Value too large for
> > defined data type
> >
> > That value is 2^63-1 (nearly 8 exabytes), and split.c
> > explicitly handles a file of that size, because that is
> > the size reported for /dev/zero on GNU/Hurd systems,
> > according to the comment.
> >
> > This fixes the test not to trigger that work-around:
> > [I'll update the commit log with the issue URL as soon as it's assigned]
>
> No feedback, so I presume no objection.
> Pushed with the mentioned commit-log addition.
>
>
> --- End Message ---