X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:message-id; q=
	dns; s=default; b=wze/ZVj8z0p6nAkD17WfdTcQrrQpAf/KMrlHEkiPcjNtXW
	BTVKGr1lRFIKvHhYMKS4L50Az9O35T0K135XIQJtWqdux5hisICRIPsALJcdVWf6
	C+DrmBCK/5FKQp/tFbmFjD2+sccrNcCuzVJRrSfEgOVBV9kaUzE/I8F+5s9IE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:message-id; s=
	default; bh=ugwD3UY0ecZ9E3fJXoREaOgv9cw=; b=BiycFdrvReqV+dGqk2eV
	SyAY1GCryI2sB3D9bF4f5+lq2F76qgmOYm3r3sTQoU+C3QiBpYqg9n7R2NkqlHv7
	fJZWtbpsHoC9264lbft8Tf+YUZySNHoDpzhPDhKVs00QoaJPmMt33wt4bU/tQnY8
	A3GbaxSAllsueY7iUgZqdrs=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=199, compares, H*UA:Webmail, inspect
X-HELO: lb1-smtp-cloud2.xs4all.net
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Sat, 02 Jan 2016 12:58:10 +0100
From: Houder <houder AT xs4all DOT nl>
To: cygwin AT cygwin DOT com
Subject: Pipes Again. (was: cmp (or echo) bug?)
Message-ID: <a33618ac83154dae265bb9906dd966e0@xs4all.nl>
X-Sender: houder AT xs4all DOT nl (nUv91CkvZ7CseC8LEnWNqQ==)
User-Agent: XS4ALL Webmail
X-IsSubscribed: yes

Hi Corinna,

As reported by David BalaÅic in "cmp (or echo) bug?" (December 25, 2015)

     https://cygwin.com/ml/cygwin/2015-12/msg00310.html

execution of

     cmp <(echo foo) <(echo bar)

from bash (note: bash!) fails (nearly always; however the rate of 
failure
may depend on specific conditions).

Failure means that "cmp" reports the two inputs as equal (wrong!).

Although at least one different reason for the failure has been 
suggested
here, I like to propose that the reason for the failure is a deficiency 
in
Cygwin itself (yes, pipes again).
(yes, I think it is Cygwin, not bash, not cmp ...)

As noted by David, "cmp" does not fail on Linux ...

As "diff" (and "stat") did NOT fail, I decided to inspect the source 
code
of "cmp" (and "diff", "stat" ...).

cmp tries to be smart (as does diff): before it actually compares the 
two
inputs, it takes a shortcut by comparing both the device (st_dev) and 
the
i-node (st_ino) of the files specified as arguments.

cmp uses fstat() to obtain device and i-node ... diff and stat use 
stat()
and lstat().

Replacing fstat() by stat() in cmp, makes cmp behave as it should!

Next I started to compare Cygwin and Linux ... (using customized code).

Basically, my customized code (t_stat.c) reads as follows:

     struct stat sb[2];
     int fd[2];

     // process the two arguments - like cmp does
     for (int f = 0; f < 2; f++)
     {
         // drop O_BINARY in case of Linux
         // replace O_RDONLY by O_RDWR for ./tstat <(cat > a) <(cat > b)
         fd[f] = open(argv[1 + f], O_RDONLY | O_BINARY); // as cmp does
         if (fd[f] < 0)
             errExit("open");
         if ( fstat(fd[f], sb + f) != 0 ) // as cmp does
             errExit("fstat");

         // appears to increase the failure rate to "always"
         close(fd[f]); // ... NOT present in cmp
     }
     printf("... arg = %s\n", argv[1]);
     displayStatInfo(sb);
     printf("... arg = %s\n", argv[2]);
     displayStatInfo(sb + 1);
     printf("fd[0] = %u, fd[1] = %u\n", fd[0], fd[1]);

Linux shows:
@@ ./t_stat <(echo foo) <(echo bar)
... arg = /dev/fd/63
File type:                FIFO or pipe
Device containing i-node: (8)   major=0   minor=8
I-node number:            5bc8 - decimal: 23496
... arg = /dev/fd/62
File type:                FIFO or pipe
Device containing i-node: (8)   major=0   minor=8
I-node number:            5bca - decimal: 23498
fd[0] = 3, fd[1] = 3

  - Linux always shows the same value for st_dev; that is, also if 
fstat() is
    replaced by stat() ...
  - Linux always shows different values for both st_ino-s (same call); 
values
    that are different from the ones in subsequent calls

Cygwin shows:
@@ ./t_stat <(echo foo) <(echo bar)
... arg = /dev/fd/63
File type:                FIFO or pipe
Device containing i-node: (c6)   major=0   minor=198
I-node number:            0 - decimal: 0
... arg = /dev/fd/62
File type:                FIFO or pipe
Device containing i-node: (c6)   major=0   minor=198
I-node number:            0 - decimal: 0
fd[0] = 3, fd[1] = 3

And sometimes, especially in case close(fd[f]) is NOT present ...

@@ ./t_stat <(echo foo) <(echo bar)
... arg = /dev/fd/63
File type:                FIFO or pipe
Device containing i-node: (c6)   major=0   minor=198
I-node number:            0 - decimal: 0
... arg = /dev/fd/62
File type:                FIFO or pipe
Device containing i-node: (c6)   major=0   minor=198
I-node number:            5c443bd7b7e540 - decimal: 25970721670292800
fd[0] = 3, fd[1] = 4

  - Cygwin shows 198 for st_dev in case fstat() is used
  - Cygwin shows 199 for st_dev in case stat() is used
  - Cygwin shows 197 for st_dev in case fstat() is used and in case the 
command
    reads as follows:
@@ ./t_stat >(cat > a) >(cat > b) # yes, the opposite case - had to try

  - Cygwin nearly always shows ZERO for both st_ino-s (same call); 
however, if
    one of the st_ino-s is NOT zero, Cygwin always shows the same value:
I-node number:            5c443bd7b7e540 - decimal: 25970721670292800

Bottom-line:

  - instrumenting cmp with the same "diagnostics", yields the same result
  - cmp fails on Cygwin, because Cygwin returns both st_ino-s as equal 
(zero).

My reason for posting this, is to help others in case they stumble over 
this
weird behaviour of Cygwin.

Regards,
Henri

=====

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple