NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/vms/19887

Internet Message Format | 1992-12-26 | 3.0 KB

Path: sparky!uunet!usc!elroy.jpl.nasa.gov!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
From: [e-mail] (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: Request help !
Date: 26 Dec 1992 05:32:24 GMT
Organization: HST Wide Field/Planetary Camera
Lines: 55
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <[e-mail]>, [e-mail] writes:
=Hi, everybody !
=
=I read a mail (I forgot the name of the sender) about recursive directory
=specification, using this command :
=
=$ CREATE /DIR [.1]
=$ SET FILE /ENTER=[.1]2.DIR 1.DIR
=
=The first time I access 1.DIR, I could see 2.DIR.
=Then, when I access 2.DIR, I could see another 2.DIR, and that 2.DIR seemed
=endless. Everytime I access the next one, I would always see another one,
=kind of getting deeper and deeper.
=
=Can someone please explain to me what in happening ?

Certainly.  A directory entry simply consists of a file name and a File
IDentification number.   Nothing in the directory entry itself says anything
about that the directory the entry's in is supposed to be called.  So, let's
take the simplest case:  1.DIR his FID (75,1,0).  So the original entry for it
says that file 1.DIR;1 in your original directory is the file with FID
(75,1,0).  Now, when you SET FILE/ENTER=[.1]2.DIR 1.DIR, you're telling VMS to
put a directory entry in file (75,1,0) that says that that directory contains
the file (75,1,0), which is to be called 2.DIR;1.  At this point, things have
become self-referential.  The file [.1]2.DIR;1 now contains an entry
associating directory 2.DIR;1 with its own FID.  This is a situation one
generally tries to avoid.

=I also tried to delete the directory :
=I delete 2.DIR first, since it's lower that 1.DIR, using this command :
=( I did this after I access 1.DIR)
=
=$ SET PROT:O:D 2.DIR
=$ DEL 2.DIR;*

Well, since [.1]2.DIR;1 and []1.DIR;1 are the same file, when you changed the
protection of 2.DIR you did the same thing to the protection of 1.DIR.  This
means that you no longer have read, write, or execute permission for 1.DIR;1.
So when you try to modify it with the command:

$ DEL 2.DIR;1

=But, instead I got error message :
=insufficient privilege or file protection violation.

Which is telling you you need to:
    $ SET PROTECTION=O=RWED 1.DIR;1
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: [e-mail] | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.