The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: norman@oclsc.org (Norman Wilson)
Subject: [TUHS] fstat(2) on pipes?
Date: Mon, 15 Aug 2016 13:47:03 -0400	[thread overview]
Message-ID: <1471283229.3510.for-standards-violators@oclsc.org> (raw)

I remember once, long ago--probably in the early 1980s--writing
a program that expected fstat on a pipe to return the amount of
data buffered in the pipe.  It worked on the system on which
I wrote the code.  Then I tried it on another, related but
different UNIX, and it didn't work.  So if POSIX/SUS don't
prescribe a standard, I don't think one should pretend there
is one, and (as I learned back then) it's unwise to depend
on the result, except I think it's fair not to expect fstat
to fail on any valid file descriptor.

I'm pretty sure that in 7/e and earlier, fstat on a pipe
reported a regular file with zero links.  There was a reason
for this: the kernel in fact allocated an i-node from a
designated pipe device (pipedev) file system, usually the
root.  So the excuse that `there's no i-node' was just wrong.

In last-generation Research systems, when pipes were streams
(and en passant became full duplex, which caused no trouble
at all but simplified life elsewhere--I think I was the one
who realized that meant we didn't need pseudo-ttys any more),
the system allocated a pair of in-core i-nodes when a pipe
was created.  As long as such an i-node cannot be accidentally
confused with one belonging to any disk file system, this
causes no trouble at all, and since it is possible to have
more than one disk file system this is trivially possible
just by reserving a device number.  (In fact by then our
in-core i-nodes were marked with a file system type as well,
and pipes just became their own file system.)  stat always
returned size 0 for (Research) stream pipes, partly because
nobody cared enough, partly because the implementation of
streams didn't keep an exact count of all the buffered data
all along the stream, just a rough one sufficient for flow
control.  Besides, with a full-duplex pipe, which direction's
data should be counted?

Returning to the original question, I'd suggest that:
-- fstat(fd) where fd is a pipe should succeed
-- the file should be reported to have zero links,
since that is the case for a pipe (unless a named pipe,
but if you support those you probably have something
else to stat anyway)
-- the file type should be IFIFO if that type exists
in xv6 (which it wouldn't were it a real emulation of
6/e, but I gather that's not the goal), IFREG otherwise
-- permissions probably don't matter much, but for
sanity's sake should be some reasonable constant.

Norman Wilson
Toronto ON


             reply	other threads:[~2016-08-15 17:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-15 17:47 Norman Wilson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-08-15 14:04 Noel Chiappa
2016-08-15 15:14 ` Random832
2016-08-15 16:56   ` Michael Kjörling
2016-08-15  0:27 Noel Chiappa
2016-08-15  0:59 ` Warren Toomey
2016-08-15  0:11 Warren Toomey
2016-08-15  0:41 ` Dave Horsfall
2016-08-15  0:54   ` Warren Toomey
2016-08-15 17:53 ` Clem Cole

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=1471283229.3510.for-standards-violators@oclsc.org \
    --to=norman@oclsc.org \
    /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 NNTP newsgroup(s).