GNU bug report logs - #22931
tests/split/filter.sh fails on an XFS file system

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22931 in the body.
You can then email your comments to 22931 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: bug-coreutils <at> gnu.org
Subject: tests/split/filter.sh fails on an XFS file system
Date: Sun, 6 Mar 2016 19:36:13 -0800

[Message part 1 (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 #8 received at 22931 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: 22931 <at> debbugs.gnu.org
Subject: Re: bug#22931: tests/split/filter.sh fails on an XFS file system
Date: Sun, 6 Mar 2016 22:38:36 -0800

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]

A possible addition is to #ifdef-out the offending code
in src/split.c, so that the original example works -- at least
on non-Hurd systems. One might argue that we should
make these tools work consistently across all systems,
but in a corner case like this, I have a slight preference
for keeping the usual-case code slightly cleaner, and
working with an edge-case file size like the one in this
example.

Message #13 received at 22931-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: 22931-done <at> debbugs.gnu.org
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 <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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.