[ace-users] BUG REPORT: NT/Unix differences not protected by
Seth Kurtzberg
2000?
Seth Kurtzberg
Machine Independent Software
Cell (602) 478-5511
Fax: (480) 614-8909
email: se...@cql.com
pager: 888-605-9296 or email 605...@skytel.com
On Wed, 5 Apr 2000, Douglas C. Schmidt wrote:
> Hi Susan,
>
> >> Found at least two system calls where the ACE wrapper doesn't
> >> provide identical behavior between Unix and NT systems. There may
> >> be others. Because I am using the wrappers to abstract away system
> >> differences, I would expect to get the same type of behavior
> >> regardless of whether I'm on NT or Unix.
>
> As usual, you can't get chicken feed out of chicken $%^@ ;-)
>
> >> 1) ACE_OS::rename when a file of the new name already exists
> >>
> >> ->AIX/SOLARIS/Digital Unix
> >>
> >> ACE_OS::rename(old, new) filters down to the system call
> >> "rename". On the aforementioned Unix systems will
> >> remove "new", subject to write access permissions on the directory.
> >> and then rename old to new
> >>
> >> ->NT
> >> ACE_OS::rename filters down to _wrename. ,
> >> This call returns with an error and sets errno to EACCESS
> >> because "new" already exists.
>
> If you know of a way to change this behavior to make it consistent and
> portable, please let us know and we'll fix it.
>
> >> 2) ACE_OS::bind on a privileged port
> >>
> >> ->AIX/SOLARIS/Digital Unix
> >> ACE_OS::bind filters down to the system call "bind". It returns
> >>
> >> EACCES The requested address is protected and the current
> >> user has inadequate permission to access it.
> >>
> >> when trying to assign to a privileged port
> >>
> >> ->NT
> >> ACE_OS::bind filters down to the system call "bind". It returns
> >> successfully regardless of the port number. I know this is because
> >> of ports not being privileged on NT (I had to research this
> >> problem when ACE didn't catch this as I'd expected)
> >>
> >> NT also seems to allow multiple apps to use the same port,
> >> privileged or not. The Unices don't.
>
> Ditto for this!
>
> Thanks,
>
> Doug
> --
> Dr. Douglas C. Schmidt, Associate Professor TEL: (949) 824-1901
> Dept of Electrical & Computer Engineering FAX: (949) 824-2321
> 616E Engineering Tower WEB: www.ece.uci.edu/~schmidt/
> University of California, Irvine, 92697-2625 NET: sch...@uci.edu
>
Kelly F. Hickel
with ACE yet), but it seems to me that the first problem should be
pretty easy to "fix" in the ACE_OS layer. At least, once you decide
which of the two behaviours you want......
Or am I (probably) missing something?
-Kelly
Andrew Bolstridge
and deleted things first! tut.
The 'fix' for the windows version of rename is to call delete (new) first,
and then rename (old, new). easy.
Don't know about that port question though. what's a privilged port? (Q. are
you running your programs with administrator privileges).
Andy.
Susan Liebeskind
> From owner-a...@cs.wustl.edu Mon Apr 10 11:23:03 2000
> X-Authentication-Warning: taumsauk.cs.wustl.edu: majordom set sender to owner-a...@cs.wustl.edu using -f
> From: Andrew Bolstridge <And...@compans.com>
> To: "'ace-...@cs.wustl.edu'" <ace-...@cs.wustl.edu>
> Subject: RE: [ace-users] BUG REPORT: NT/Unix differences not protected by
> ACE wrappers
> Date: Fri, 7 Apr 2000 10:39:58 +0100
> MIME-Version: 1.0
>
> almost certainly not. imagine, renaming a file only to find that its gone
> and deleted things first! tut.
But that is the POSIX way of doing things. Certainly it is done that way
on the 3 Posix compliant Unix boxes I am working with.
From the Solaris man page for rename
If the link named by new exists, it will be removed and old
will be renamed to new.
From Digital Unix
If the TO parameter already exists it is first removed...
(don't have easy access to AIX man pages but it works the same way)
> The 'fix' for the windows version of rename is to call delete (new) first,
> and then rename (old, new). easy.
Yes, and that is what I did in my code. For my small universe (AIX, Solaris,
Digital Unix and NT) it's fine.
But is that the fix for the ACE distribution? I can't answer that
because I don't know about all the platforms on which ACE is officially
supported. Does it pretty much come down to NT on one side and Posix
compliance on the other?
In any case, For someone like me, with a Unix background, POSIX
compliance is the natural solution. But for someone like you, Andy,
who has an NT orientation, you will not like that implementation. (I
interpret your "tut" comment regarding POSIX behavior at the start of
your reply as evidence of displeasure :-)
>
> Don't know about that port question though. what's a privilged port? (Q. are
> you running your programs with administrator privileges).
Privileged/reserved ports are something again related to POSIX
compliance. Unix boxes reserve the first 1024 ports for use by root.
MOrtal processes cannot use these port numbers. For the 'bind' case I
mentioned, I could certainly find some NT API and check if the account
has administrative privileges (which I did in this case) and also check to
see if there is another process using that port already (don't know if
there is an API to do this). So it could be done, if this was important.
In this case, it wasn't a showstopper on NT for me.
****
All this raises a "Really Big Question" IMHO...
There is a philosophical concern to be addressed about whether or
not the ACE bare bones OS wrappers should provide the same behavior on
all platforms.
If the same behavior will not be enforced, my feeling is those wrappers
which work differently on NT vs. Unix vs. other platforms should be
flagged. That's a BIG undertaking. Failing that, maybe a big caveat
in the man page that says "investigate the behavior on different
platforms before using these APIS. You may be surprised."
If the same behavior IS to be enforced, then the question is "in which
OS's favor do you resolve the differences?" I've only mentioned two
cases here. There are others places where the underlying OS is visible
(some of the thread wrappers for example). My personal preference is
for POSIX compliance because most OS's implement that. Windoze does to a
limited extent.
A compromise: what about enforcing consistency in increments, starting
off with adding the caveat about difference being possible in the bare bones
wrappers? For those APIs where we already know about the differences,
fix them where we can. Note them where they can't.
This could be done gradually (starting with the ACE_OS:rename API as
Andy suggests and I implemented, noting the issue of reserved ports in
the bind call, etc.). As each API is checked and found consistent, add
a comment to the documentation. Users should assume that the API
hasn't been checked if no comments are added.
---
Thoughts from the ACE group? I know I've fought for (and won) a
variant of this battle way back when. I just checked in an old
ChangeLog from 1998, and I see the entry concerning my request for
consistent default thread creation semantics. In the ChangeLog entry,
Nanbor wrote "This is important for unifying thread behavior on
different platforms that have various default thread creation
policies" Again, IMHO, this is just a logical extension of the same problem,
consistency on different platforms.
---
and to further make my point, I hereby present you with...
The ACE Serenity Prayer.
"God grant me
the serenity to accept the ACE_OS::wrappers I cannot make consistent,
the courage to change the ones I can, and
the wisdom to know the difference :-)"
(how could I resist????? :-) :-)
Susan
Douglas C. Schmidt
>> There is a philosophical concern to be addressed about whether or
>> not the ACE bare bones OS wrappers should provide the same behavior on
>> all platforms.
Right -- ideally, it should be consistent.
>> If the same behavior will not be enforced, my feeling is those wrappers
>> which work differently on NT vs. Unix vs. other platforms should be
>> flagged. That's a BIG undertaking. Failing that, maybe a big caveat
>> in the man page that says "investigate the behavior on different
>> platforms before using these APIS. You may be surprised."
Yup.
>> If the same behavior IS to be enforced, then the question is "in which
>> OS's favor do you resolve the differences?" I've only mentioned two
>> cases here. There are others places where the underlying OS is visible
>> (some of the thread wrappers for example). My personal preference is
>> for POSIX compliance because most OS's implement that. Windoze does to a
>> limited extent.
Right.
>> A compromise: what about enforcing consistency in increments, starting
>> off with adding the caveat about difference being possible in the bare bones
>> wrappers? For those APIs where we already know about the differences,
>> fix them where we can. Note them where they can't.
If you'd like to contribute fixes and improvements to the ACE
documentation we'll be more than happy to add them.
Susan Liebeskind
> From owner-a...@cs.wustl.edu Mon Apr 10 16:32:05 2000
> X-Authentication-Warning: taumsauk.cs.wustl.edu: majordom set sender to owner-a...@cs.wustl.edu using -f
> Date: Mon, 10 Apr 2000 15:31:17 -0500 (CDT)
> To: ace-...@cs.wustl.edu
> Subject: Re: [ace-users] BUG REPORT: NT/Unix differences not protected by
>
>If you'd like to contribute fixes and improvements to the ACE
>documentation we'll be more than happy to add them.
Whoa, Doug! Not so fast on the autoreply boilerplate. I won't let
you go that easy :-)
------
I did supply in my posting wording for a caveat that could go in the
man pages . As mentioned, this could be a bare minimum to alert people to
this serious crack in the OS abstraction. If you need different wording,
let me know.
SL> Failing that, maybe a big caveat in the man page that says
SL> "investigate the behavior on different platforms before using these APIS.
SL> You may be surprised."
------
Having dealt with the warning of the problem, then comes the issue of
trying to solve the problem. And this brings me back to the question
of "in whose OS's favor are differences resolved?"
From the previous posting....
SL>> If the same behavior IS to be enforced, then the question is "in which
SL>> OS's favor do you resolve the differences?" I've only mentioned two
SL>> cases here. There are others places where the underlying OS is visible
SL>> (some of the thread wrappers for example). My personal preference is
SL>> for POSIX compliance because most OS's implement that. Windoze does to a
SL>> limited extent.
DS> Right.
Does "right" mean "Yes, go for POSIX compliance?"
And because I don't know anything about realtime platforms, like
VxWorks, and have no access to them, I would have no way to see how my
changes work on these platforms. Are these realtime platforms a breed
unto themselves? I don't think this is a problem I can contribute fixes for
without thinking about all the platforms the ACE group, Riverace and OCI
must support. Which brings up the next point...
---
The corollary of deciding on the standard for portability is "would
these changes break existing code?" That's a question for Steve Huston,
at Riverace, and his support customers, along with OCI.
Perhaps you would want to add the consistent APIS with some
official prefix, like posix (if you choose posix compliance), e.g.
ACE_OS::rename_posix
which would mean posix compliant rename behavior on all platforms?
-----
Again, I think this is a big problem, one that at the very least should
be duly noted. Certainly I got lulled into complacency on a few items on
my NT port as a result of the wrappers, and consequently, ended up with a
few bugs on the NT port. I am sure my experience is not atypical.
But...
before I or anyone else tried to *solve* this problem, most likely in
the piecemeal fashion one-API-at-a-time I proposed, I would want some
direction as to the right way to proceed That means the answers to the
following questions should be clearly stated:
- is the goal POSIX compliance?
- is backward compatibility necessary?
Thwack! Ball back in your court.
Susan
Douglas C. Schmidt
> I did supply in my posting wording for a caveat that could go in the
> man pages . As mentioned, this could be a bare minimum to alert
> people to this serious crack in the OS abstraction. If you need
> different wording, let me know.
We need more than a wording -- we need patches for the specific header
code in question.
> Does "right" mean "Yes, go for POSIX compliance?"
Yes.
> And because I don't know anything about realtime platforms, like
> VxWorks, and have no access to them, I would have no way to see how
> my changes work on these platforms. Are these realtime platforms a
> breed unto themselves?
Yes.
> The corollary of deciding on the standard for portability is "would
> these changes break existing code?" That's a question for Steve
> Huston, at Riverace, and his support customers, along with OCI.
That's correct.
> Perhaps you would want to add the consistent APIS with some
> official prefix, like posix (if you choose posix compliance), e.g.
>
> ACE_OS::rename_posix
>
> which would mean posix compliant rename behavior on all platforms?
I'll let David Levine address this since he and Luther Baker are
working on the POSIX-compliance stuff for "POSIX ACE" (PACE).
> before I or anyone else tried to *solve* this problem, most likely in
> the piecemeal fashion one-API-at-a-time I proposed, I would want some
> direction as to the right way to proceed That means the answers to the
> following questions should be clearly stated:
>
> - is the goal POSIX compliance?
Yes.
> - is backward compatibility necessary?
I'll let Steve Huston address this, but in general, the goal should be
to have a consistent API, i.e., "same semantics on different
platforms."
Steve Huston
> From the previous posting....
>
> SL>> If the same behavior IS to be enforced, then the question is "in which
> SL>> OS's favor do you resolve the differences?" I've only mentioned two
> SL>> cases here. There are others places where the underlying OS is visible
> SL>> (some of the thread wrappers for example). My personal preference is
> SL>> for POSIX compliance because most OS's implement that. Windoze does to a
> SL>> limited extent.
>
> DS> Right.
>
I'm not Doug, but I'd say yes, POSIX should be the standard of
compliance.
> The corollary of deciding on the standard for portability is "would
> these changes break existing code?" That's a question for Steve Huston,
> at Riverace, and his support customers, along with OCI.
Any change might. But as you've seen, not changing it also has bad,
unexpected effects. A change in functionality to unify behavior is easy
to justify. A change in API is much harder to justify.
> Perhaps you would want to add the consistent APIS with some
> official prefix, like posix (if you choose posix compliance), e.g.
>
> ACE_OS::rename_posix
>
> which would mean posix compliant rename behavior on all platforms?
Yuck.
> -----
>
> Again, I think this is a big problem, one that at the very least should
> be duly noted. Certainly I got lulled into complacency on a few items on
> my NT port as a result of the wrappers, and consequently, ended up with a
> few bugs on the NT port. I am sure my experience is not atypical.
>
> But...
>
> before I or anyone else tried to *solve* this problem, most likely in
> the piecemeal fashion one-API-at-a-time I proposed, I would want some
> direction as to the right way to proceed That means the answers to the
> following questions should be clearly stated:
>
> - is the goal POSIX compliance?
Yes, IMHO.
> - is backward compatibility necessary?
API compatibility is necessary. Functional backward compatibility is
pretty hard to do, no ;-) As long as I get good notice in the form of
email (preferably) or a very well-written note in ChangeLog I can get it
in the release notes - you all do read the release notes, right?
>
> Thwack! Ball back in your court.
and a quick volley back at ya ;-)
-Steve
--
Steve Huston Riverace Corporation
Email: shu...@riverace.com http://www.riverace.com
ACE Kits, Support, Consulting (508) 541-9183, FAX 541-9185
Installable Kits at http://www.riverace.com/ACE_Kits/kit-store.html
Douglas C. Schmidt
> I'm not Doug, but I'd say yes, POSIX should be the standard of
> compliance.
Cool -- we ended up with the same conclusion, which is a "Good
Thing"[TM]. Therefore, Susan, all that remains is for someone to help
migrate this stuff in the "POSIX" direction...
"Thwack" ;-)
Chris Cleeland
> > I'm not Doug, but I'd say yes, POSIX should be the standard of
> > compliance.
>
> Cool -- we ended up with the same conclusion, which is a "Good
> Thing"[TM]. Therefore, Susan, all that remains is for someone to help
> migrate this stuff in the "POSIX" direction...
>
> "Thwack" ;-)
What kind of court are ya'll playing in? Or, is this the double-single
match? ;-)
--
Chris Cleeland, clee...@cs.wustl.edu, http://www.cs.wustl.edu/~cleeland/
(Former) Research Associate, Washington University Dept. of Computer Science
"Everybody wants prosthetic foreheads on their real heads."
Susan Liebeskind
> From owner-a...@cs.wustl.edu Tue Apr 11 10:15:23 2000
> X-Authentication-Warning: taumsauk.cs.wustl.edu: majordom set sender to owner-a...@cs.wustl.edu using -f
> From: "Douglas C. Schmidt" <sch...@cs.wustl.edu>
> To: ace-...@cs.wustl.edu
> Subject: Re: [ace-users] BUG REPORT: NT/Unix differences not protected by
>
>
> > I'm not Doug, but I'd say yes, POSIX should be the standard of
> > compliance.
>
> Cool -- we ended up with the same conclusion, which is a "Good
> Thing"[TM]. Therefore, Susan, all that remains is for someone to help
> migrate this stuff in the "POSIX" direction...
>
So what is PACE, the POSIX ACE effort? Is that something designed to
address exactly this issue?
What is the official POSIX standard # for OS calls? It's 1003.something
or other, I think. the IEEE web site is not cooperating withe me right now.
HOw does the Unix 98 standard fit into all this? I'm a bit confused.
I know there is a Posix Standard but I'm not sure which one. Or as
Bullwinkle J Moose once said of his tattered Hush-a-boom Recipe
"I know how much, just not what of"
> "Thwack" ;-)
Point, and match. Gotta quit playing and get back to work!
I'll submit my change for rename and header file changes suitable for
fishwrapping in a bit.
Andrew Bolstridge
> But that is the POSIX way of doing things. Certainly it is
> done that way
> on the 3 Posix compliant Unix boxes I am working with.
>
'tut' is something I use (in a semi-serious way) to bait unix-lovers. for
the record, I was a unix chappy a while back, then OS/2, and now NT -
writing cross platform code....
besides, I think this particular way of doing stuff (deleting files to
rename others) is broken. NT fixed this IMHO.
>
>
> But is that the fix for the ACE distribution? I can't answer that
> because I don't know about all the platforms on which ACE is
> officially
> supported. Does it pretty much come down to NT on one side and Posix
> compliance on the other?
>
> In any case, For someone like me, with a Unix background, POSIX
> compliance is the natural solution. But for someone like you, Andy,
> who has an NT orientation, you will not like that implementation. (I
> interpret your "tut" comment regarding POSIX behavior at the start of
> your reply as evidence of displeasure :-)
frankly, my dear, its going to break anyway. so it might as well be in
someone else's code to take the blame ;-)
I think it should be unix-oriented, as there's many more unixes to support
than the 1 (true?) NT platform - gotta support the lowest common denominator
as well, for those where an API is present on many systems.
> >
> > Don't know about that port question though. what's a
> privilged port? (Q. are
> > you running your programs with administrator privileges).
>
> Privileged/reserved ports are something again related to POSIX
> compliance. Unix boxes reserve the first 1024 ports for use by root.
> MOrtal processes cannot use these port numbers. For the
> 'bind' case I
> mentioned, I could certainly find some NT API and check if
> the account
> has administrative privileges (which I did in this case) and
> also check to
> see if there is another process using that port already
> (don't know if
> there is an API to do this). So it could be done, if this
> was important.
> In this case, it wasn't a showstopper on NT for me.
>
unfortunately, NT does not restrict the use of ports below 1024 to anybody -
let alone Administrator. though, for true cross platform compatibility, you
could always check if (p < 1024) ... (hence Doom can play on port 666, if
you remember that far back)
I don't know of an API to see is a port is in use... oh, of course there is
- the system will always return a WSAEADDRINUSE error.
> If the same behavior IS to be enforced, then the question is
> "in which
> OS's favor do you resolve the differences?" I've only mentioned two
> cases here. There are others places where the underlying OS
> is visible
> (some of the thread wrappers for example). My personal preference is
> for POSIX compliance because most OS's implement that.
> Windoze does to a
> limited extent.
>
I'd say this needed to be done, and is a great idea, but I have a message
queue to modify (as I get time) from the last time I sent a mail to Doug
about an improvement to ACE...
What ACE needs is a bulletin board setting up (what am I saying!) with a
section on each class group, where people can post bits of documentation to
(why did I type this!)
No Doug, I can't implement a BBS for you ;-)
Cheers Andy.
Douglas C. Schmidt
>> So what is PACE, the POSIX ACE effort?
Right -- it's goal is two-fold:
1. Create a C-level API for what's currently in ACE_OS so that it
can be accessed purely from C. This is intended for embedded
programmers who just want to use the ACE OS adapation layer
and nothing else.
2. Make the ACE OS adapation layer have consistent POSIX semantics
whereever possible.
>> Is that something designed to address exactly this issue?
Right.
>> What is the official POSIX standard # for OS calls? It's
>> 1003.something or other, I think.
David Levine can answer this since he's got a copy of it.
>> I'll submit my change for rename and header file changes suitable
>> for fishwrapping in a bit.
Cool, thanks!
McNiel, Jeff
> What ACE needs is a bulletin board setting up (what am I saying!) with a
> section on each class group, where people can post bits of documentation
> to
> (why did I type this!)
>
> No Doug, I can't implement a BBS for you ;-)
>
> Cheers Andy.
>
[Jeff McNiel] (While I'm not volunteering either, :) What about a
Wiki-Wiki thing like Cunningham's???
Not matter what, IMHO it would be a "Good Thing"[TM] if we had an
easy way to collectively work on documentation for ACE+TAO. Especially a
current FAQ. It seems that no one (other than the commercial supporters)
has a lot of time to do docs but if it were easy to edit online, a la the
Wiki-Wiki, maybe we could at least keep an up-to-date FAQ - I will volunteer
to do some collating, but I don't know how to go about settingup something
like this. What's the general feeling on this?
- Jeff
Douglas C. Schmidt
>> Not matter what, IMHO it would be a "Good Thing"[TM] if we had
>> an easy way to collectively work on documentation for ACE+TAO.
>> Especially a current FAQ. It seems that no one (other than the
>> commercial supporters) has a lot of time to do docs but if it were
>> easy to edit online, a la the Wiki-Wiki, maybe we could at least
>> keep an up-to-date FAQ - I will volunteer to do some collating, but
>> I don't know how to go about settingup something like this. What's
>> the general feeling on this?
I think this is a great idea. I *definitely* do not have time to work
on this, but if some enterprising ACE+TAO users would like to set it
up, it sounds very useful.
Take care,
Steve Huston
> Not matter what, IMHO it would be a "Good Thing"[TM] if we had an
> easy way to collectively work on documentation for ACE+TAO. Especially a
> current FAQ. It seems that no one (other than the commercial supporters)
> has a lot of time to do docs but if it were easy to edit online, a la the
> Wiki-Wiki, maybe we could at least keep an up-to-date FAQ - I will volunteer
> to do some collating, but I don't know how to go about settingup something
> like this. What's the general feeling on this?
I'm doing some work on Riverace's web site... part of that is setting up
a Faq-O-Matic for ACE. That should help out quite a bit.
No promises on when it'll be done, but it's in progress - probably
within a few weeks.
Andrew Bolstridge
apps on!
Let us know when you've got it up and running though ;-)
Cheers.
[snip]
> No need; find a server and install FAQ-O-Matic and open it
> up for folks to
> put in this information.
>
> -cj