9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: dhog@plan9.cs.su.oz.au dhog@plan9.cs.su.oz.au
Subject: [comp.os.linux.misc] Help wanted, Plan9 a piece of junk!
Date: Wed, 16 Aug 1995 02:39:16 -0400	[thread overview]
Message-ID: <19950816063916.1vVsajUrGBnNz1memM4UA--arl7yGQqArG6eKEt5d4o@z> (raw)

>Love that subject...

He can't even spell Linux...  ;-)

>Since everything in Plan 9 is a file, the message 'file does not
>exist' is probably the least useful and most seen message.

I've noticed that sometimes the message is printed even when
there is no actual file that couldn't be opened.  The reason for
this appears to be:

(1) Some programs use errstr when reporting errors which don't actually set errstr
(2) open() can set errstr as a side effect, even when the call succeeds.  This is
  due to the implementation of union directories -- walk() tries each directory
  in a union in turn until it succeeds, and errstr is set to 'file does not exist' as
  a side effect of a failed attempt.  Thus any program which, say, uses files in
  /dev, will have errstr set to 'file does not exist' instead of 'no error'.  In fact,
  it's worse than that, since "/" is a union directory, opening any file in the
  namespace will set errstr!

I'm not sure what the best way to fix this is.  Ideally, open() should not change
errstr at all if it succeeds, but this would require wasteful copying of errstr in
every call to walk() on a union directory.  The alternative is to just blindly clear
u->error[0] on a sucessful open() -- cheaper, but is it The Right Thing?

Anyway, here is a program to demonstrate the problem:

-----------------
#include <u.h>
#include <libc.h>

void
try(char *file)
{
	char err[ERRLEN];

	strcpy(err, "no error, dude");
	fprint(2, "\nbefore opening %s, set errstr = '%s'\n", file, err);
	errstr(err);
	if (open(file, OREAD) < 0)
		fprint(2, "open %s failed!: %r\n", file);
	else
		fprint(2, "after opening %s, errstr = '%r'\n", file);
}

void
main(int argc, char *argv[])
{
	fprint(2, "on program entry, errstr = '%r'\n");

	try("/dev/null");
	try("/adm/users");
	try("#p/1/status");
	exits(0);
}
--------------------
Here's the output when I run it:

on program entry, errstr = 'file does not exist'

before opening /dev/null, set errstr = 'no error, dude'
after opening /dev/null, errstr = 'file does not exist'

before opening /adm/users, set errstr = 'no error, dude'
after opening /adm/users, errstr = 'file does not exist'

before opening #p/1/status, set errstr = 'no error, dude'
after opening #p/1/status, errstr = 'no error, dude'
--------------------

P.S.  If Plan9 is junk, what does that make Windows 3.1?






             reply	other threads:[~1995-08-16  6:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-08-16  6:39 dhog [this message]
  -- strict thread matches above, loose matches on Subject: below --
1995-08-25  6:28 dhog
1995-08-25  4:14 Johnson
1995-08-24  8:49 dhog
1995-08-24  7:27 Johnson
1995-08-23 15:13 Victor
1995-08-22 11:25 dhog
1995-08-22  6:18 Vadim
1995-08-21 22:54 forsyth
1995-08-21  4:59 Vadim
1995-08-19 13:32 forsyth
1995-08-19  5:03 pete
1995-08-16 21:16 Scott
1995-08-16 14:42 Steve_Kilbane
1995-08-16  5:45 dhog
1995-08-16  1:12 forsyth
1995-08-15 16:00 Bill
1995-08-15 15:24 presotto
1995-08-15 14:53 Greg
1995-08-15 13:29 jmk
1995-08-15 13:28 Ture
1995-08-15 12:38 David
1995-08-15 10:29 dhog
1995-08-14 21:46 Bill

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=19950816063916.1vVsajUrGBnNz1memM4UA--arl7yGQqArG6eKEt5d4o@z \
    --to=dhog@plan9.cs.su.oz.au \
    /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).