[cs631apue] cp(1) test cases

[Jan Schaumann]

Hello,

In class, one of you asked whether the system cp(1)
should be passing the tests.  It should.

However, when I ran the command in class, it failed:

$ sh testcp.sh -p `which cp`
Expected success, but command failed:
  /bin/cp big file
Files 'file1' and 'file2' differ.
testcp.sh: 2/29 tests failed.
$ 

The reason for this is unfortunately not obvious, but
has to do with the default tmpfs under /tmp being
rather small.

/tmp is not on the normal filesystem; by default,
NetBSD creates /tmp as a "tmpfs" -- see
mount_tmpfs(8).  That is, it creates a filesystem in
memory, since files under /tmp are intended to be
temporary in nature and usually quite small.  Keeping
the filesystem in memory makes it significantly faster
than writing this (temporary) data to disk.

But since it exists only in memory, it can only be so
big.  The default installation created it as 256MB in
size.

The testcp.sh script tries to create a "big" test file
of 2GB in size under the temporary directory.  Since
/tmp is only 256 in size, it will fail to do that, and
the 'big' file will be 256 MB in size and thus fill
/tmp completely.  When the test then tries to copy the
big file to another file in the same directory, it
will fail to do so, as there is no more space.

So how can you test your command?  As previously
mentioned, you can set the TMPDIR environment variable
to make the script use a different location instead of
/tmp:

$ env TMPDIR=/var/tmp sh testcp.sh -v -v -v -p `which cp`
=> Checking usage...
===> Checking '/bin/cp'...
[...]
===> Test case: big...
===> Checking '/bin/cp big file'...
===> Comparing 'big' to 'file'...
===> Checking '/bin/cp small existing'...
===> Comparing 'small' to 'existing'...
===> Comparing 'file1' to 'file2'...
Files 'file1' and 'file2' differ.
testcp.sh: 1/30 tests failed.
$

Now this fails in a different place than before.  In
particular, this is the fifo test.  And this is a
failure that actually _is_ unexpected.

The system cp(1) creates a zero sized file:

apue$ mkfifo fifo
apue$ echo foo >fifo &
apue$ cp fifo file2
apue$ ls -l fifo file2
prw-r--r--  1 jschauma  wheel  0 Sep 21 22:58 fifo
-rw-r--r--  1 jschauma  wheel  0 Sep 21 22:58 file2
apue$

That is, cp(1) erroneously creates a zero-length file
when reading from a fifo.  I had had reported this two
years ago:

https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54564

This was fixed, but for some reason the fix was not
pulled into the latest release (I'm not sure why,
still looking to find out), which is why our test here
still fails.

All of this is just to give you an example of (a) how
you can dig into why a test may fail, and (b) that
sometimes the problem is indeed in the open source
tools you use, but that (c) you can report such
failures and even fix them yourself.

-Jan