Subject: bug#22931: closed (Re: bug#22931: tests/split/filter.sh fails on an XFS file system)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 08 Mar 2016 21:02:02 +0000

Your bug report

#22931: tests/split/filter.sh fails on an XFS file system

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
22931: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22931
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#22931: tests/split/filter.sh fails on an XFS file system
From: Jim Meyering <[email-masked]>
To: [email-masked]
Date: Tue, 8 Mar 2016 13:01:08 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

On Sun, Mar 6, 2016 at 7:36 PM, Jim Meyering <[email-masked]> 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.

Subject: tests/split/filter.sh fails on an XFS file system
From: Jim Meyering <[email-masked]>
To: [email-masked]
Date: Sun, 6 Mar 2016 19:36:13 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

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]
From 889415ab359c943ee4c358f8c5fb07bca95a4ead Mon Sep 17 00:00:00 2001
From: Jim Meyering <[email-masked]>
Date: Sun, 6 Mar 2016 16:38:01 -0800
Subject: [PATCH] tests: avoid false-failure of split/filter.sh on XFS

* tests/split/filter.sh: Use OFF_T_MAX-1 rather than OFF_T_MAX
as the size of a test file, to avoid false failure on an XFS file
system (or any file system permitting a file of size OFF_T_MAX).
---
 tests/split/filter.sh | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/split/filter.sh b/tests/split/filter.sh
index a93008b..bd2f210 100755
--- a/tests/split/filter.sh
+++ b/tests/split/filter.sh
@@ -52,9 +52,13 @@ returns_ 1 split -n 1/2 --filter='true' /dev/null 2>&1 || fail=1
 # where they would result in a non zero exit from split.
 yes | head -n200K | split -b1G --filter='head -c1 >/dev/null' || fail=1

+# Do not use a size of OFF_T_MAX, since split.c applies a GNU/Hurd
+# /dev/zero workaround for files of that size.  Use one less:
+N=$(expr $OFF_T_MAX - 1)
+
 # Ensure that "endless" input is ignored when all filters finish
 timeout 10 sh -c 'yes | split --filter="head -c1 >/dev/null" -n r/1' || fail=1
-if truncate -s$OFF_T_MAX zero.in; then
+if truncate -s$N zero.in; then
   timeout 10 sh -c 'split --filter="head -c1 >/dev/null" -n 1 zero.in' || fail=1
 fi

-- 
2.7.2