🚀 go-pugleaf

In article <1991Feb16.000101.4149@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) writes:

   When two (or more) "mv" commands try to rename the same file OR DIRECTORY
   to two DIFFERENT names at the same time, the result can be two separate
   hard links to the same inode.  In the case of directories, "ln" (or the
   underlying system call) will refuse to allow this to happen except if the
   uid is root.

This is not unreasonable on a multi-processor with a re-entrant
kernel. On a uniprocessor, the rename() system call is "atomic"
because no other process can be executing kernel code (and renaming
the same files) at the same time. In DYNIX, it is possible for several
processes to be executing rename() at the same time on different
processors. Although hardware locks are used to synchronise access to
the inodes as their link counts are changed, this will not prevent the
behaviour you describe from happening.

		Jim

If you are talking about DYNIX (4.2BSD), this is not true; the rename(2)
system call is used and it is atomic. Assuming you aren't using the mv(1) in
the att universe, of course.

If you are talking about DYNIX/ptx (SVR3.2), then you are correct. There is
no rename(2) call, mv(1) is not atomic (it uses link(2) and unlink(2)), and
you are SOL. That's just the way System V works.

[Editorial Comment: Companies that give the same name (or a trivial variation,
like the version code) to radically different operating systems should be
lynched by their justifiably outraged customers. That includes the old Gould,
which had who-knows-how-many different things all called UTX; Sun, which last
I knew is going to call their SVR4 port "SunOS 5.0"; and many others. Sequent
chose to walk a very well trodden path, and I know of other companies that
plan to follow.]

<csg>

In article <145463@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>If you are talking about DYNIX (4.2BSD), this is not true; the rename(2)
>system call is used and it is atomic. Assuming you aren't using the mv(1) in
>the att universe, of course.

The att universe version of mv_dir uses the rename(2) system call.

The ucb universe is just as described, the standard 4.2BSD version of mv(1).

>If you are talking about DYNIX/ptx (SVR3.2), then you are correct. There is
>no rename(2) call, mv(1) is not atomic (it uses link(2) and unlink(2)), and
>you are SOL. That's just the way System V works.

That's not how DYNIX/ptx works.  There is a rename(2) system call in
DYNIX/ptx and mv(1) has been changed to use it.  rename(2) has been
there from the beginning of DYNIX/ptx.  I believe mv(1) was changed to
use rename(2) for the V1.1 release.

[Editorial Comment:  Remember, I'm a just an en-g-neer, not a spokesman:]
One of the ideas behind calling the new operating system DYNIX/ptx was
to give the impression that it is based on the original DYNIX.  Many
important features from DYNIX (such as rename(2)) were added to
DYNIX/ptx while still maintaining industry standards.  (SVR3.2, SVID,
POSIX, XPG, etc)

Personally, I wanted to call it DYNIX_Bob, but no one listened to me.  :-) :-)
-- 
Pete_Bob Apple						Sequent Computer Systems
petebob@sequent.com, sequent!petebob			15450 S.W. Koll Parkway
Bob is not just a name..				Beaverton, Oregon 97006
It's a way of life.. 					(503) 626-5700

In article <53625@sequent.UUCP> petebob@eng3.UUCP (Pete Apple) writes:
?In article <145463@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
?>If you are talking about DYNIX (4.2BSD), this is not true; the rename(2)
?>system call is used and it is atomic. Assuming you aren't using the mv(1) in
?>the att universe, of course.
?
?The att universe version of mv_dir uses the rename(2) system call.

It took AT&T long enuf to realize they needed mkdir, rmdir, and rename
system calls. Unfortunately, they still insist on this nonsense mvdir command.

?The ucb universe is just as described, the standard 4.2BSD version of mv(1).

Except that the standard isn't 4.2 anymore. It's 4.3. And beyond.
There are many of your customers who are distressed at the low
baud rate at which bits flow from UCB to each of your companies.

?>If you are talking about DYNIX/ptx (SVR3.2), then you are correct. There is
?>no rename(2) call, mv(1) is not atomic (it uses link(2) and unlink(2)), and
?>you are SOL. That's just the way System V works.

Ooooh, that's scary! However, I wonder about the AT&T broken ln syndrome.
Somewhere along the line, AT&T broke ln(1) so that if you do:

	who > a; ls > b; ln a b

you will get one file with two links successfully,
rather than two different files and failure.

?That's not how DYNIX/ptx works.  There is a rename(2) system call in
?DYNIX/ptx and mv(1) has been changed to use it.  rename(2) has been
?there from the beginning of DYNIX/ptx.  I believe mv(1) was changed to
?use rename(2) for the V1.1 release.

Well, Carl, that'll teach you to post flames in a hostile newsgroup :-)

?[Editorial Comment:  Remember, I'm a just an en-g-neer, not a spokesman:]
?One of the ideas behind calling the new operating system DYNIX/ptx was
?to give the impression that it is based on the original DYNIX.  Many
?important features from DYNIX (such as rename(2)) were added to
?DYNIX/ptx while still maintaining industry standards.  (SVR3.2, SVID,
?POSIX, XPG, etc)

And SVR3.2 isn't the standard either. SVR4 is.

And don't forget the most important standard: BSD.

I hope that PTX will not include this dual universe nonsense.
A unified approach (such as the one taken by Sun and Dec, probably others)
is much better. Users want the best features from both systems.

?Personally, I wanted to call it DYNIX_Bob, but no one listened to me.  :-) :-)
?-- 
?Pete_Bob Apple						Sequent Computer Systems
?petebob@sequent.com, sequent!petebob			15450 S.W. Koll Parkway
?Bob is not just a name..				Beaverton, Oregon 97006
?It's a way of life.. 					(503) 626-5700

I think you're too close to Twin Peaks :-)
-- 
		[rbj@uunet 1] stty sane
		unknown mode: sane

I have to second R. B. Jim's comments about Sequent software.  It's pitiful.

Sequent's dual-universe approach is especially bad.  You can't write a program
that uses both memset() and mkdir() although such a program runs on the Unix
systems from Sun, Dec, MtXinu, SGI, HP, NeXT, and Encore -- and in either
universe of an Apollo.

Sequent doesn't even seem to understand.  They're so proud that they're finally
moving to SVR3.2 while that the rest of the world is moving to SVR4 -- which,
please note, is the one that merges in most of the BSD features people want.

I have been passing on these complaints to everyone who asks how we like our
Sequent.  Rock-solid hardware, pathetic software.

    Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
    +1 602 621 4325     gmt@cs.arizona.edu     110 57 16 W / 32 13 45 N / +758m

In comp.sys.sequent, gmt@cs.arizona.edu (Gregg Townsend) writes:
>I have to second R. B. Jim's comments about Sequent software.  It's pitiful.

I'm real tired of seeing this stuff.  I happen to thing that Sequent
has done a great job on software.  I agree, it's not leading edge stuff,
but it works, and it provides all the features I need.

>I have been passing on these complaints to everyone who asks how we like our
>Sequent.  Rock-solid hardware, pathetic software.

I word it this way:
	   Rock-solid hardware, Rock-solid software.

Sun offers leading edge software, and they have to pay the price
for doing that.  Every few months I see another article like this:

In comp.security.announce, cert-advisory-request@CERT.SEI.CMU.EDU writes:
>
>CA-91:01                       CERT Advisory
>                             February 21,  1991
>                        SunOS /bin/mail Vulnerability

>Sun Bug ID  : 1047340
>Synopsis    : /bin/mail can be caused to invoke a root shell if given the
>              (im)proper arguments.

Someone should write a song: "50 ways to be root on a Sun".

I've never seen a single bug report like this about DYNIX.

DYNIX does have some bugs, and so does the Sequent hardware, but it's
the best integration of hardware and software that I've seen in a
long time.

Curt Welch
curt@oasys.dt.navy.mil
Code 3531
David Taylor Research Center (A Navy Lab)
Bethesda, MD
(301) 227-1428

In article <6055@oasys.dt.navy.mil> curt@oasys.dt.navy.mil (Curt Welch) writes:
>>I have to second R. B. Jim's comments about Sequent software.  It's pitiful.
>
>I'm real tired of seeing this stuff.  I happen to thing that Sequent
>has done a great job on software.  I agree, it's not leading edge stuff,
>but it works, and it provides all the features I need.

You're absolutely correct - they're right there on the trailing edge.  For
single system installations, again, I suspect you are correct that the system
will work well.  In ones like ours where you have a multitude of different
systems, many of which are trying to keep up, it is a more obvious and more
likely to cause problems.  I'm also tired of seeing it - and saying it.  It
would be highly desirable if Sequent would do something so we wouldn't find
ourselves even having to discuss it.

>I word it this way:
>	   Rock-solid hardware, Rock-solid software.

Yes, but petrified is also quite solid by definition.

>Sun offers leading edge software, and they have to pay the price
>for doing that.  Every few months I see another article like this:
>
>In comp.security.announce, cert-advisory-request@CERT.SEI.CMU.EDU writes:
>>
>>CA-91:01                       CERT Advisory
>>                             February 21,  1991
>>                        SunOS /bin/mail Vulnerability
>
>I've never seen a single bug report like this about DYNIX.

I have seen such reports, but only from Sequent, and only after we harrassed
them seriously about not providing such information.  They do not seem to like
to even admit that they have security problems.  Their attitude was the same
old one: we don't want to publicize the problem since people could exploit it.
Both the network manager and I pressed them on this and now we do get Sequent
security notices on hardcopy - typically very terse, little info on the
specifics and a comment that a patch may be available.  So, maybe Sequent is
just treating you the way did us and you're incorrectly assuming that there
are no such problems with your version of Dynix.

>DYNIX does have some bugs, and so does the Sequent hardware, but it's
>the best integration of hardware and software that I've seen in a
>long time.
>
>Curt Welch
>curt@oasys.dt.navy.mil

I fully agree that the hardware is good (except the 8mm - I'll keep saying
that until we have a unit that works for 12 months).  However, the OS needs
a lot of updating and ptx is NOT it either.
-- 
-----------------------------------------------------------------------------
Keith Pyle                                UUCP: ...!cs.utexas.edu!execu!keith
Manager, Data Processing Services Dept.   Internet: keith@execu.com
Execucom Systems Corp.
108 Wild Basin Road
Austin, Texas 78746                       Ma Bell: 512-327-7070
-----------------------------------------------------------------------------

In article <6055@oasys.dt.navy.mil> curt@oasys.dt.navy.mil (Curt Welch) writes:
>In comp.sys.sequent, gmt@cs.arizona.edu (Gregg Townsend) writes:
>>I have to second R. B. Jim's comments about Sequent software.  It's pitiful.
>
>I'm real tired of seeing this stuff.  I happen to thing that Sequent
>has done a great job on software.  I agree, it's not leading edge stuff,
>but it works, and it provides all the features I need.
...
>I word it this way:
>	   Rock-solid hardware, Rock-solid software.

Do you use NFS?  Or do you try to port PD/GNU software to DYNIX?
Just wondering...

I suspect that if you developed software that had to be portable
across Unix implementations or did a lot of Unix systems programming
you would feel quite differently.  And such portability and 
interoperability is a main reason many people use Unix.

But, hey, it all depends what you want your Sequent for.  Ours
was bought for a cycle server for our undergraduate program,
and for that it does an outstanding job.  It would probably
be a reasonable if not excellent machine for a parallel database
engine.  But not for the development and distribution of software.
 
>Sun offers leading edge software, and they have to pay the price
>for doing that.  Every few months I see another article like this:
>
>In comp.security.announce, cert-advisory-request@CERT.SEI.CMU.EDU writes:
>>
>>CA-91:01                       CERT Advisory
[etc.]

If people really want to be more risk free and have their hands held
they can get VMS...

--
Dave Bakken, bakken@cs.arizona.edu, uunet!arizona!bakken, +1 602 621 4089
I am Iraq,I am an island.And Iraq feels no pain.And an island never cries.PSimon
You know I've heard about people like me, but I never made the connection...
Don McClean, from the song ``Crossroads'' in album American Pie

In article <6055@oasys.dt.navy.mil>, curt@oasys.dt.navy.mil (Curt Welch) writes:
> In comp.sys.sequent, gmt@cs.arizona.edu (Gregg Townsend) writes:
> >I have to second R. B. Jim's comments about Sequent software.  It's pitiful.
> 
> I'm real tired of seeing this stuff.  I happen to thing that Sequent
> has done a great job on software.  I agree, it's not leading edge stuff,
> but it works, and it provides all the features I need.
> 
> >I have been passing on these complaints to everyone who asks how we like our
> >Sequent.  Rock-solid hardware, pathetic software.
> 
> I word it this way:
> 	   Rock-solid hardware, Rock-solid software.

Not only is it not leading edge, its so far behind the edge that you
can't even see wherethe edge is. It doesnt work reliably. It does not
provide the features I need. As far as I know, they're all software
problems. If you put a lot of effort into it, you can usually beat
the system into doing what you want. Its ashame that you have
to doi so much unnecessary work.

Given the complete system hangs (as in push the "reset button to
"continue" running) we've been experiencing several times per week,
"rock solid" would indeed describe the system performance. But then you
really can't do much computing with a solid rock, can you?

If we were to measure the downtime of our 1 Sequent against the
downtime of our dozen Suns conbined,  the Sequent downtime would be an
order of magnitude higher. I long for the ability of running "unstable"
Sun software. Question: Which is better? 1) "buggy" Sun lock managers
for NFS that don't work 1% of the time or 2) "non-existant" but 
rock solid Sequent lock managers?

The fact that they are putting effort into System V Release THREE says
a lot about the software of this company. Not content with shipping
obsolete and broken Berkeley variants, they want to expand their market
share by shipping obsolete and broken ATT variants at the same time
they're abandoning their users of the obsolete Berkeley variants (Did
you notice that their PTX abomination is the only OS available on the
new S16? Not even a compatibility library. If you used sockets, expect
to rewrite everything in TLI. [of course this library will be provided
"someday"])

---rick

p.s. Sequent's got the same security bugs with /bin/mail you're nagging
sun about. Sun at least made the effort to notify their customers.

I'm already running fixed Sun binaries. With luck, I'll see it fixed in
Dynix 3.2 which is probably due out in mid 1994 (If it doesnt slip...)

(Ever notice that the Dynix release schedule takes longer and slips
more times than the BSD release schedule? I suppose its another attempt
at Berkeley compatibility even if the customers dont want that level of
compatibility...)