public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Houder <houder@xs4all.nl>
To: cygwin@cygwin.com
Subject: Pipes Again. (was: cmp (or echo) bug?)
Date: Sat, 02 Jan 2016 11:58:00 -0000	[thread overview]
Message-ID: <a33618ac83154dae265bb9906dd966e0@xs4all.nl> (raw)

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

             reply	other threads:[~2016-01-02 11:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-02 11:58 Houder [this message]
2016-01-02 12:17 ` Pipes Again. (was: cmp (or echo) bug?) -- typo corrected Houder
2016-01-03 22:47 ` Pipes Again. (was: cmp (or echo) bug?) -- more correction Houder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a33618ac83154dae265bb9906dd966e0@xs4all.nl \
    --to=houder@xs4all.nl \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).