[Info-vax] Container files are set to grow in importance on the IT road ahead

[John Reagan]

On Saturday, February 6, 2016 at 12:25:05 PM UTC-5, Kerry Main wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> > John Reagan via Info-vax
> > Sent: 06-Feb-16 9:20 AM
> > To: info-vax at info-vax.com
> > Cc: John Reagan <>
> > Subject: Re: [New Info-vax] Container files are set to grow in importance
> > on the IT road ahead
> > 
> > On Friday, February 5, 2016 at 7:55:04 PM UTC-5, Kerry Main wrote:
> > > > -----Original Message-----
> > > > From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf
> > Of
> > > > John Reagan via Info-vax
> > > > Sent: 05-Feb-16 10:53 AM
> > > > To: info-vax at info-vax.com
> > > > Cc: John Reagan <>
> > > > Subject: Re: [New Info-vax] Container files are set to grow in
> > importance
> > > > on the IT road ahead
> > > >
> > > > On Friday, February 5, 2016 at 8:50:06 AM UTC-5, Kerry Main wrote:
> > > > > > -----Original Message-----
> > > > > > From: Info-vax [mailto:info-vax-bounces at info-vax.com] On
> > Behalf
> > > > Of hb
> > > > > > via Info-vax
> > > > > > Sent: 04-Feb-16 12:03 PM
> > > > > > To: info-vax at info-vax.com
> > > > > > Cc: hb <end.of at inter.net>
> > > > > > Subject: Re: [New Info-vax] Container files are set to grow in
> > > > importance
> > > > > > on the IT road ahead
> > > > > >
> > > > > > On 02/04/2016 03:40 PM, Craig A. Berry wrote:
> > > > > > > On 2/4/16 7:54 AM, Kerry Main wrote:
> > > > > > >>> -----Original Message-----
> > > > > > >>> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On
> > > > Behalf
> > > > > > Of hb
> > > > > > >
> > > > > > >>> Hard links do not point from one disk to another. So
> > something
> > > > else
> > > > > > was
> > > > > > >>> used by GNV.
> > > > > > >
> > > > > > >> Well, there must be a hard or soft link of some sort because
> > after
> > > > the
> > > > > > >> fact,
> > > > > > >> I did a dir... on all the non-system disk GNV sub directories and
> > a
> > > > > > >> number
> > > > > > >> of system dir's showed up. Hence, the original delete/tree
> > cmd
> > > > > > continued
> > > > > > >> deleting on the system disk.
> > > > > > >
> > > > > > > It's possible that the POSIX root business and related mount
> > points
> > > > are
> > > > > > > what you tripped over.  If you figure out how those things work,
> > > > please
> > > > > > > explain them to me :-).  I don't know if "SET NOROOT" or "SET
> > ROOT
> > > > > > NL:"
> > > > > > > might've prevented the disaster, but they'd be worth a try.  Or
> > > > umnt
> > > > > > on
> > > > > > > whatever mount points were aimed at your system disk, if any.
> > > > > > >
> > > > > >
> > > > > > It's all open source so it is easy to understand :-) I know nothing
> > > > > > about these mount points and mnt/umnt. I would expect mnt to
> > > > mount
> > > > > > any
> > > > > > VMS directory into the POSIX file system tree. The output of mnt
> > > > seems
> > > > > > to support this:
> > > > > > bash-4.3$ mnt
> > > > > > DISK$ODS5_1:[VMS$COMMON.gnv]usr.DIR;1 on /usr
> > > > > > DISK$ODS5_1:[VMS$COMMON.gnv]man.dir;1 on /man
> > > > > > DISK$ODS5_1:[VMS$COMMON.gnv]lib.DIR;1 on /lib
> > > > > > DISK$ODS5_1:[VMS$COMMON.gnv]include.dir;1 on /include
> > > > > > DISK$ODS5_1:[VMS$COMMON.gnv]etc.dir;1 on /etc
> > > > > > DISK$ODS5_1:[VMS$COMMON.gnv]bin.DIR;1 on /bin
> > > > > > bash-4.3$
> > > > > > So I can think of an environment where the POSIX root is in a
> > > > > > sub-directory of the installed GNV kit - on a non-system disk, and
> > a
> > > > > > (default/customized?) mount point under the root mounts a
> > > > directory
> > > > > > from
> > > > > > the system disk. I didn't try but it is quite possible that a VMS DIR
> > > > > > and/or DELETE will follow the mount points (which in the SHOW
> > ROOT
> > > > > > directory look like directories - as far as I can see) from the
> > > > > > non-system disk to the system disk.
> > > > > >
> > > > > > I really would like to know how the directory structure was,
> > before it
> > > > > > was deleted. And I still think that DELETE/TREE is innocent, here,
> > as a
> > > > > > "normal" DELETE with "..." would have done the same damage.
> > > > >
> > > > > Just to clarify - I also do not believe the delete/tree has an issue.
> > > > >
> > > > > It is much more likely due the way the GNV kit is setup with
> > hard/soft
> > > > > links and the fact that I installed the kit on a non-system disk.
> > > > >
> > > > > Having stated this, it is a big wake-up call (for me anyway) as I
> > would
> > > > > never have expected a delete/tree cmd on a non-system disk to go
> > off
> > > > > and start deleting many system files on the system disk .. when $
> > Help
> > > > xxx
> > > > > says something to the effect "file not found", you know you are in
> > > > trouble.
> > > >
> > > > Yep and GNV stopped doing that.  It wasn't good to put indirect
> > access to
> > > > system files from the non-system disk.  However, you must have
> > done
> > > > that DEL/TREE with privs enabled, right?  The standard protection
> > checks
> > > > would prevent a non-priv'd user from deleting those files regardless
> > of
> > > > how you got there.
> > >
> > > Re: priv's enabled .. yeas, was using SYSTEM to install GNV
> > >
> > > Btw, what do you mean when you say GNV stopped doing that?
> > >
> > > This happened approx. 2 weeks ago using the latest GNV kit.
> > >
> > > HP-i64vms-gnv-v0300-001-1.zip
> > >
> > 
> > Was that fresh install or an "upgrade" for a prior version?
> > 
> 
> This was fresh GNV install on non-system disk on a rx2600 E8.2-4.
> 
> > Looking at the PSX$UP_STARTUP.COM file, the code that makes the
> > mount points is commented out in the version I'm looking at.
> > 
> 
> Line 79 perhaps (depending on previous test)?
> $   mnt 'f$trnlnm("PSX$ARCH_ROOT")'[000000] "/PSX$ARCH_ROOT"
> 
> [snip...]
> 
> 
> Regards,
> 
> Kerry Main
> Kerry dot main at starkgaming dot com

I'll let John Malmberg know if he doesn't spot this these posts.