jbuck@epimass.UUCP (Joe Buck) (04/22/87)
If you're a Eunice user, and you keep your news in /usr/spool/news,
you can't have five-part newsgroups such as comp.sys.ibm.pc.digest
(do I see Erik Fair's work in that name?). This is because on VMS,
the directory name would be
DISK:[EUNICE.USR.SPOOL.NEWS.COMP.SYS.IBM.PC.DIGEST]
and VMS only allows subdirectories to be eight levels deep.
If your Eunice site is a leaf node, you can cope with the problem
by aliasing the group to a different name. I suggest
(in aliases)
comp.sys.ibm.pc.digest comp.sys.ibm-pc.digest
This is because, when you post to the group, it gets converted
to mail by replacing all the dots with dashes, giving an address
of
comp-sys-ibm-pc-digest@backbone-site
Using the above alias, the mailing address will be the same.
As maintainer of the Eunice 2.11 news, I could attempt to hack
something in. It would also be possible to make SPOOLDIR be
/spool/news. But do we really need five-level names? Is it
too late to use a shorter name? Or the name I suggested above?
--
- Joe Buck {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck
seismo!epiwrl!epimass!jbuckfair@ucbarpa.Berkeley.EDU.UUCP (04/22/87)
In the referenced article, Joe Buck <jbuck@epimass.UUCP> writes: >If you're a Eunice user, and you keep your news in /usr/spool/news, >you can't have five-part newsgroups such as comp.sys.ibm.pc.digest >(do I see Erik Fair's work in that name?). You do NOT. I don't like that name any better than you do (at least not the "digest" part), but I have no alternative that would be acceptable to the USENET community. Concerning depth, I see no reason why we shouldn't go arbitrarily deep when it appears to be appropriate, and in the cited case, it is appropriate. One day, I hope that someone writes an interface that views the USENET name-space as a tree (which it is), and plays depth games of one sort or another. It would be an interesting change from the current paradigm, anyway... As for the problem, since this is a VMS limitation (and therefore unlikely to change soon), you should go to some type of mapping system. Messy, I know, but I don't think that we should allow the limitations of VMS systems to hinder the USENET, any more than I think that we should allow the limitations of, say, B news 2.9 sites to hinder USENET. I'm somewhat surprised that Eunice didn't encounter this problem and solve it already. Did Kashtan just work around it all over? Does MS/DOS have this problem too? If so, I'd be interested to know what Lauren Weinstein did in UULINK. And how about VM/CMS? There was something about this sort of problem in that ";login:" article about the netnews implementation for VM/CMS that Princeton did... Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
IRWIN@pucc.UUCP (04/22/87)
In article <18509@ucbvax.BERKELEY.EDU>, fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes: >In the referenced article, Joe Buck <jbuck@epimass.UUCP> writes: >>If you're a Eunice user, and you keep your news in /usr/spool/news, >>you can't have five-part newsgroups such as comp.sys.ibm.pc.digest > ... >And how about VM/CMS? There was >something about this sort of problem in that ";login:" article about the >netnews implementation for VM/CMS that Princeton did... Yes, since VM/CMS identifies a file by (user,minidisk,filename,filetype), and I find it most practical that all articles have the same (user,minidisk), I have used a mapping which is much less convenient that the usual 2.11 one. Filename and filetype are each limited to 8 characters, so I map the newsgrup names into 4-digit numbers and use the filetype for the article number. It will support 10^4-1 newsgroups and 10^8-1 articles, but I sure wish I could use a tree structure instead. Irwin Tillman BITNET: IRWIN@PUCC Princeton University UUCP: {allegra,ihnp4,cbosgd}!psuvax1!PUCC.BITNET!IRWIN
perry@vu-vlsi.UUCP (04/23/87)
In article <1082@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes: >If you're a Eunice user, and you keep your news in /usr/spool/news, >you can't have five-part newsgroups such as comp.sys.ibm.pc.digest >(do I see Erik Fair's work in that name?). This is because on VMS, >the directory name would be > > DISK:[EUNICE.USR.SPOOL.NEWS.COMP.SYS.IBM.PC.DIGEST] > >and VMS only allows subdirectories to be eight levels deep. Perhaps you can get around this by defining a logical name for a directory such that the top level newsgroups will be the first level of sub-directory, e.g. $ assign/translation=conceal _hsc000$dua0:[eunice.usr.spool.news.] news (note: use physical ^^^ device name need ^ that .) Then news:[comp], news:[comp.sys], etc. would be the newsgroup locations, and you can then have groups up to 8 levels deep. I'm not too familiar with the Eunice parts of the news software, but I presume that somehow SPOOLDIR could be defined using a NEWS: logical name like this (/news/ ?) ...Rick perry@vu-vlsi.UUCP, perry@vuvaxcom.BITNET Dr. Rick Perry, Department of Electrical Engineering Villanova University, Villanova, PA 19085, 215-645-4224
jbuck@epimass.UUCP (Joe Buck) (04/24/87)
In article <1082@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes: >>If you're a Eunice user, and you keep your news in /usr/spool/news, >>you can't have five-part newsgroups such as comp.sys.ibm.pc.digest >>... This is because on VMS, the directory name would be >> >> DISK:[EUNICE.USR.SPOOL.NEWS.COMP.SYS.IBM.PC.DIGEST] >> >>and VMS only allows subdirectories to be eight levels deep. In article <724@vu-vlsi.UUCP> perry@vu-vlsi.UUCP (Rick Perry) writes: > Perhaps you can get around this by defining a logical name for a >directory such that the top level newsgroups will be the first level of >sub-directory, e.g. > >$ assign/translation=conceal _hsc000$dua0:[eunice.usr.spool.news.] news >(note: use physical ^^^ device name need ^ that .) > >Then news:[comp], news:[comp.sys], etc. would be the newsgroup locations, >and you can then have groups up to 8 levels deep. I'm not too familiar >with the Eunice parts of the news software, but I presume that somehow >SPOOLDIR could be defined using a NEWS: logical name like this (/news/ ?) Unfortunately, Eunice can't deal with rooted logical names correctly (well, at least it's a documented bug -- maybe it will be fixed in the new version). Eunice does a fairly complete job of emulating 4.1bsd, by the way; the #ifdefs for VMS in the code don't really change that much. They emulated the system calls and then used roughly the same source code as Berkeley did for the utilities. You don't notice you're not on Unix (other than the different way typeahead is done by the VMS terminal driver) until you hit an edge (like trying to create a nineth-level directory). So what am I going to do about it? Nothing! Eunice news sites have two options: define SPOOLDIR to be /spool/news or something like that, or use an alias (comp.sys.ibm-pc.digest is probably best). -- - Joe Buck {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck seismo!epiwrl!epimass!jbuck
leres@ucbarpa.Berkeley.EDU (Craig Leres) (04/25/87)
The the new (4.3 BSD) Eunice has symbolic links. It's too bad more people don't have it since it allows easy solution of the too deep directory problem. I haven't tried it, but it might be possible to move the bin, etc, lib, and usr directories from dua0:[eunice] to dua0:[000000]. If successful, you could define usr to be dua0:[usr.] instead of dua0:[eunice.usr.]. This would let you get one level deeper (and makes the previously mentioned six part ibm name work). Craig
fair@ucbarpa.Berkeley.EDU (Erik E. Fair) (04/25/87)
In article <1094@epimass.UUCP> jbuck@epimass.UUCP (Joe Buck) writes: >So what am I going to do about it? Nothing! Eunice news sites have >two options: define SPOOLDIR to be /spool/news or something like >that, or use an alias (comp.sys.ibm-pc.digest is probably best). NOTE: if you use the "alias" approach, be sure that your site is only a "leaf" node of the network (that is, you only have one netnews neighbor), so that this change does not propagate out onto the network. Erik E. Fair ucbvax!fair fair@ucbarpa.berkeley.edu
jbuck@epimass.UUCP (Joe Buck) (04/26/87)
In article <18575@ucbvax.BERKELEY.EDU> leres@ucbarpa.Berkeley.EDU (Craig Leres) writes: >The the new (4.3 BSD) Eunice has symbolic links. It's too bad more >people don't have it since it allows easy solution of the too deep >directory problem. Is it really a 4.3BSD version of Eunice, or just Eunice version 4.3? There's a difference, you know. Eunice version 4.2 looks like 4.1bsd, NOT like 4.2. What other differences are there? What is its release status? Why does Wollongong send me hefty software maintenance bills but not let us know about new releases? (Just got another bill last week). Has anyone brought up 2.11 news under 4.3 Eunice yet? (You could get rid of those fake symbolic links I put in there). -- - Joe Buck {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck seismo!epiwrl!epimass!jbuck
jbuck@epimass.UUCP (Joe Buck) (04/26/87)
In article <18577@ucbvax.BERKELEY.EDU> fair@ucbarpa.Berkeley.EDU (Erik E. Fair) writes: >NOTE: if you use the "alias" approach, be sure that your site is only a >"leaf" node of the network (that is, you only have one netnews >neighbor), so that this change does not propagate out onto the >network. Certainly. Of course, anyone who would use a Eunice site to feed other sites, given the lethargic sluggishness and unreliability of Eunice systems, is a true masochist. -- - Joe Buck {hplabs,ihnp4,sun,ames}!oliveb!epimass!jbuck seismo!epiwrl!epimass!jbuck
levy@ttrdc.UUCP (04/26/87)
In article <724@vu-vlsi.UUCP>, perry@vu-vlsi.UUCP (Rick Perry) writes: < >the directory name would be < > DISK:[EUNICE.USR.SPOOL.NEWS.COMP.SYS.IBM.PC.DIGEST] < >and VMS only allows subdirectories to be eight levels deep. < Perhaps you can get around this by defining a logical name for a < directory such that the top level newsgroups will be the first level of < sub-directory, e.g. < $ assign/translation=conceal _hsc000$dua0:[eunice.usr.spool.news.] news < < Then news:[comp], news:[comp.sys], etc. would be the newsgroup locations, < and you can then have groups up to 8 levels deep. I'm not too familiar < with the Eunice parts of the news software, but I presume that somehow < SPOOLDIR could be defined using a NEWS: logical name like this (/news/ ?) This works fine under DCL. I tried it under Eunice -- a bust. Yes, I created a system logical name and used assign/trans=conceal. Yes, I put the name in sys$system:root. Eunice "knew" what the logical name meant but still refused to go or make directories deeper than 8 levels relative to the device top level directory [0,0]. She would go one level deeper but no more in accessing directories put there using DCL IF she was given a full UNIX pathname, but I couldn't cd into those directories. Also a "pwd" would print out the pathname as it would have if the logical name had never been used. Apparently, Eunice translates concealed logical names too. <sigh> Probably better to have [news] be an actual top level directory on the disk. Eunice can handle that just fine. < ...Rick perry@vu-vlsi.UUCP, perry@vuvaxcom.BITNET < Dr. Rick Perry, Department of Electrical Engineering < Villanova University, Villanova, PA 19085, 215-645-4224 -- |------------dan levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an engihacker @ | vax135}!ttrdc!ttrda!levy | at&t computer systems division | Disclaimer: try datclaimer. |--------skokie, illinois--------|
kashtan@sri-unix.ARPA (David Kashtan) (04/26/87)
Eunice 4.3 is indeed 4.3bsd! The version that I gave to Wollongong is based on the 4.3bsd-beta release and they are, at this very moment, bringing up the "official" 4.3bsd release. David
steven@pearl.berkeley.edu (Stephen the Greatest) (04/29/87)
Hey guys, I am absolutely sick of these messages talking about 5-part names. Can't somebody talk about something intelligent about EUNICE? This 5-part stuff has been going on for ages. - Stephen
libes@nbs-amrf.UUCP (05/01/87)
I'm not sure if I want to know this, but just what is the reason
that VMS cannot handle >8 levels of directories? Is it really that
impossible to change?
Surely even VMS users must feel this is an annoyance, too.
Particularly, with the larger and larger file systems one finds on
VAXen these days, it seems surprising that DEC never fixed (uhh,
changed) this.
Perhaps it is coming. After all, the last major release of VMS did
increase the name space substantially (which was very helpful to
Eunice).
(Please do not flame one way or the other about the rest of the VMS
file system. I have no wish to hear another UNIX vs VMS debate.)
Don Libes {seismo,mimsy}!nbs-amrf!libestihor@acf4.UUCP (Stephen Tihor) (05/13/87)
The 8 level limit was explained as being an arbitrary number to prevent problems on endless looping if the directory structure was changed from a simple tree into a complex graph with a loop in it. It also permited he computation of an upper limit on fully qualified file name size. This is useful since most VMS tools actually check buffer limits for too long file names rather than just trashing their internal memory and doing arbitrary damage like most unix tools. Of course since DEC has annoucned that they are supporting a limit of 1000 characters as a maximum file name the 8 level limit could be changed.
dhesi@bsu-cs.UUCP (05/15/87)
In article <14750001@acf4.UUCP> tihor@acf4.UUCP (Stephen Tihor) valiantly tries to explain the 8-level subdirectory limit in VAX/VMS thus: >The 8 level limit was explained as being an arbitrary number to prevent >problems on endless looping if the directory structure was changed from a >simple tree into a complex graph with a loop in it.... Not a plausible explanation. The VMS directory structure is not permitted to be a graph with a loop in it. Even if it did support a generalized graph structure one day, that still would be no justification for such a small limit. For example, 4.3BSD does support a complex graph structure via symbolic links, but will translate up to 20 symbolic links before giving diagnosing an infinite loop. > ...It also permited he >computation of an upper limit on fully qualified file name size. This is >useful since most VMS tools actually check buffer limits for too long >file names rather than just trashing their internal memory and doing >arbitrary damage like most unix tools. Since directory names can be about 39 characters long, and filenames can be about 80 characters long, the calculated upper limit on a complete pathname would be about 500 characters, allowing some space for a network node name or device name or logical name. I doubt that most VMS utilities use 500-character fixed-size arrays to avoid checking filename length. What is more likely that limits such as this one are necessary to maintain conceptual integrity in an operating system that spends much of its time comparing various parameters against their defined limits. (Try "show process/quota" to see a long list.) Examples of other meaningless limits are: command procedures may have only up to 8 parameters; passwords may not contain most special characters. WHAT? YOU CAN'T HAVE A PASSWORD WITH A * OR / IN IT? WHY?? Conceptual integrity. Don't leave home without it. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
tihor@acf4.UUCP (Stephen Tihor) (05/18/87)
Sorry but that is the explaination Andy Goldstein gave for the 8 item limit. You might disagree. Submitting an SPR about this "problem" might produce the suitable canned answer. When last I discussed the subject there were indications that the File System group might be preparing to actually restrict VMS directory heirarchies to something very close to a simple tree and remove some of the existing restrictions. If you are convicned that VMS directory trees are really simple trees take a good look at your system disk or type: $ create/dir [loopy] $ set file/enter=[loopy]loopy.dir [000000]loopy.dir $ dir [ineinei K
leres@ucbarpa.Berkeley.EDU (Craig Leres) (05/19/87)
The filesystem VMS uses is called files-11, level 2. It's basically the same file system used by RSX-11M (called files-11, level 1) with the addition of futuristic features such as named directories. Level 1 is upwards compatible with level 2. This means you can mount RSX disks under VMS. This feature eases migration from the PDP-11 to the Vax (or so DEC claimed). But the price is high; you get to run with a filesystem designed in the stone ages. There are bound to be limits that are ridiculous by today's standards. The directory depth limit doesn't bother me nearly as much as the lack of performance the VMS filesystem displays. (For the most part) it does 512 byte disk I/O. Note that the BSD "fast" filesystem does 8k disk I/O by default. But instead of making trivial changes (like allowing directories to get 12 levels deep instead of 8) why don't we throw VMS away and start over? Trying to patch design flaws in over a MILLION lines of bliss and assembler is not my idea of fun. (And VMS is a prime example of why you shouldn't pay programmers by the line.) Craig
dhesi@bsu-cs.UUCP (05/19/87)
In article <18960@ucbvax.BERKELEY.EDU> leres@ucbarpa.Berkeley.EDU (Craig Leres) writes: >But instead of making trivial changes (like allowing directories to get >12 levels deep instead of 8) why don't we throw VMS away and start >over? But that's exactly what some people have done already. The result is now called 4.3BSD. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
egisin@orchid.UUCP (05/19/87)
In article <18960@ucbvax.BERKELEY.EDU>, leres@ucbarpa.Berkeley.EDU (Craig Leres) writes: > The directory depth limit doesn't bother me nearly as much as the lack > of performance the VMS filesystem displays. (For the most part) it does > 512 byte disk I/O. Note that the BSD "fast" filesystem does 8k disk I/O > by default. I'm pretty sure the default for disk I/O by RMS for sequential files is 16 blocks, or 8K. The C RTL (and Eunice?) bypass most of RMS for Stream-LF files and do block I/O with 512 byte blocks.
tihor@acf4.UUCP (Stephen Tihor) (05/21/87)
the number of blocks allocated and read in a "chunk" is set by the disks cluste factor (set to 4 for 2K basic units) and the RMS multiblock counts that determine how many blocks are read ahead/written behind when another I/O is called for. If Eunice is bypassing this entirely without doing the same itself that could explain some performance problems. In general VMS I/O speeds are low compared to commerical systems like IBMs but reasonable compared to other supermini operating systems.