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

Internet Message Format | 1992-12-24 | 3.5 KB

Path: sparky!uunet!wupost!spool.mu.edu!agate!ucbvax!lrw.com!leichter
From: [e-mail] (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: RE: Request help !
Message-ID: <[e-mail]>
Date: 24 Dec 92 21:54:06 GMT
Sender: [e-mail]
Distribution: world
Organization: The Internet
Lines: 74


    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 ?

    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;*

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

Ever hear of the sorcerer's apprentice?  If you play games with features of
VMS (or any system) that you don't understand, be prepared to be bitten!

As Gasty Gloesener pointed out in a previous message, what you have actually
done is created loop in the directory tree:  There is a single directory with
two names, 1.DIR and 2.DIR.  The 2.DIR directory appears within the 1.DIR
directory.  If you want an interesting display, try doing:

    $ DIRECT [.1...]

Note how you see the same thing at deeper and deeper levels.  Note also that
the display stops after a while:  RMS limits you to 8 levels of directory
nesting, so even though there is a loop in the directory structure, it cuts
things off after going down 8 levels.

Every file on the system, including a directory file, has a unique internal
identification known as a File ID, or FID for short.  If you try the same
directory command with the /FILE_ID qualifier, you will see that unique
identification number (it's conventionally displayed as three numbers in
parentheses, like (227,117,0)), which will be the same at every level in
the output, indicating that you are seeing the same file over and over again.

Mr. Gloesener also explained why you got the particular error message you did:
When you changed the protection on the 2.DIR directory, you also automatically
changed it on the 1.DIR directory, since they are the SAME directory, under
different names.  So now you've denied yourself READ access to 1.DIR, and can
no longer get to 2.DIR.  You can avoid that, as he suggested, but changing the
protection to O:RWED.

However, if you do that and try to delete 1.DIR, you'll STILL fail, with a
different error message.  This time, you'll get:  "Directory file is not
empty".  RMS won't let you delete a directory that contains files.  Normally,
you could just delete everything from the directory - but the only thing "in"
[.1] is 2.DIR, which is the same file - so deleting IT fails with yet another
error message:  "File access conflict" (which, BTW, I can't exactly explain,
though it makes sense in broad terms).

There IS a solution:  You have to "undo" the synonym you created with
SET FILE/ENTER.  The "reverse" of this command is SET FILE/REMOVE.  If you
do:

    $ SET FILE/REMOVE [.1]2.DIR;

you'll find that you are back to where you where after you first created [.1],
with an empty directory.  If the protection allows it, you can now delete it
with no further problems.
                            -- Jerry