GNU bug report logs -
#22931
tests/split/filter.sh fails on an XFS file system
Previous Next
Reported by: Jim Meyering <jim <at> meyering.net>
Date: Mon, 7 Mar 2016 03:37:01 UTC
Severity: normal
Done: Jim Meyering <jim <at> meyering.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Tue, 8 Mar 2016 13:01:08 -0800
with message-id <CA+8g5KHKueXXWOzU8vS3LP5KTvP2bH3d0dGQbwx-+yPOkQow3Q <at> mail.gmail.com>
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
help-debbugs <at> gnu.org.)
--
22931: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22931
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
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 (text/x-patch, attachment)]
[Message part 5 (message/rfc822, inline)]
On Sun, Mar 6, 2016 at 7:36 PM, Jim Meyering <jim <at> meyering.net> 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.
This bug report was last modified 9 years and 128 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.