paine@fungus.dec.com (Willy Paine) (10/22/89)
I have SCO Unix 3.2 and SCO told me that B News binaries for Xenix is fully compatible with Unix 3.2. I got B News from SCO only about a month ago. After I installed (I tried upgrade) into Unix 3.2 and copied B News from Xenix/386 using tape, there is problem with postnews and rnews but rn, readnews and vnews work good. On Unix 3.2 I got error message for postnews: inews: Directory permission problem in /tmp Article not posted - exit status 256 in rnews, I found log in /usr/lib/news saying: Directory permission problem in /tmp It is very strange because /tmp is very clean and has 777 permission. Found many temp file left after rnews and postnews with -rw-rw-rw permission with news in both owner and group. My only important modification after porting into Unix 3.2 is changing passwd and group id to match with news. I have checked /usr/lib/news and /usr/spool/news very well. I am still waiting for Development Package for Unix 3.2 for about a month and I am told that I might get one in next three weeks. Thanks advanced for your help and your time... willy p.s. also uunet!nwnexus!seaeast!willyp
brad@looking.on.ca (Brad Templeton) (10/22/89)
In article <8910220254.AA05389@decwrl.dec.com> paine@fungus.dec.com (Willy Paine) writes: > >On Unix 3.2 I got error message for postnews: > >inews: Directory permission problem in /tmp >Article not posted - exit status 256 Unix 3.2 is POSIX compliant. That means that if you pass a filename longer than 14 chars, it is not truncated, the open fails. B news does this, and so it fails. There is an #ifdef, FOURTEENMAX that solves the problem. Define it. As for debate about POSIX's choice, this is not the place. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
caf@omen.UUCP (Chuck Forsberg) (10/22/89)
In article <8910220254.AA05389@decwrl.dec.com> paine@fungus.dec.com (Willy Paine) writes:
:On Unix 3.2 I got error message for postnews:
:
:inews: Directory permission problem in /tmp
:Article not posted - exit status 256
:
Thanks to Posix, 15+ character file names now bounce.
There's a #ifdef in the news sources to limit the length of
temp filenames to 14 characters.
In this respect, what Posix needs is SVR4 (supposedly with
gigantic long file names).rickf@pmafire.UUCP (rick furniss) (10/23/89)
Read the manual about the C2 security regaurding the sticky bit use. /tmp comes with the sticky bit set, which controls access to deletions etc. in that directory. A very neat idea as far as I can see. You will probably have to remove the sticky bit to fix the problem. Rick Furniss
henry@utzoo.uucp (Henry Spencer) (10/23/89)
In article <37127@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >Unix 3.2 is POSIX compliant. That means that if you pass a filename longer >than 14 chars, it is not truncated, the open fails. It should be noted that "POSIX compliant" does not suffice as an explanation for this particular behavior. This behavior is *optional* in POSIX; the alternative is the way Unix historically did it, i.e. just ignore the extra characters. That is, blame AT&T, not POSIX, for this decision. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
cpcahil@virtech.uucp (Conor P. Cahill) (10/25/89)
In article <1989Oct23.152647.27702@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > In article <37127@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: > >Unix 3.2 is POSIX compliant. That means that if you pass a filename longer > >than 14 chars, it is not truncated, the open fails. > > It should be noted that "POSIX compliant" does not suffice as an explanation > for this particular behavior. This behavior is *optional* in POSIX; the > alternative is the way Unix historically did it, i.e. just ignore the extra > characters. That is, blame AT&T, not POSIX, for this decision. This is not a "feature" of standard System V Rel 3.2 as released by Interactive, and Bell Tech. When the poster mentioned it in this group I assumed it was a "feature" of SCO UNIX 3.2. So don't blame AT&T nor POSIX, just blame SCO. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
allbery@NCoast.ORG (Brandon S. Allbery) (10/25/89)
As quoted from <1989Oct23.152647.27702@utzoo.uucp> by henry@utzoo.uucp (Henry Spencer): +--------------- | In article <37127@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: | >Unix 3.2 is POSIX compliant. That means that if you pass a filename longer | >than 14 chars, it is not truncated, the open fails. | | It should be noted that "POSIX compliant" does not suffice as an explanation | for this particular behavior. This behavior is *optional* in POSIX; the | alternative is the way Unix historically did it, i.e. just ignore the extra | characters. That is, blame AT&T, not POSIX, for this decision. +--------------- Henry, this was SCO's choice. I don't recall 386/ix having this particular wart. ++Brandon -- Brandon S. Allbery: allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)* >>> Shall we try for comp.protocols.tcp-ip.eniac next, Richard? <<<
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (10/26/89)
In article <1989Oct24.214243.418@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: | This is not a "feature" of standard System V Rel 3.2 as released by Interactive, | and Bell Tech. When the poster mentioned it in this group I assumed it was | a "feature" of SCO UNIX 3.2. So don't blame AT&T nor POSIX, just blame SCO. Actually how about the user? SCO didn't make up the feature, and certainly I can't "blame" them for implementing a POSIX feature which helps me provide security on a system. The user could disable this feature, it is in the manual. You might lay the blame on the implementors of news for having an implementation which triggers this behavior. SCO is the only vendor currently shipping this level of security. If you don't need it that doesn't mean you should "blame" them for it, be glad you run a system which doesn't need it. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon