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

[Kerry Main]

> -----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.

Now where is my VMS wastebasket and/or undelete command?

:-)

Regards,

Kerry Main
Kerry dot main at starkgaming dot com