[Info-vax] detecting links made with SET FILE/ENTER

[Phillip Helbig---undress to reply]

In article <86886387-fbd3-402c-9418-7e36eadbe776 at googlegroups.com>, Hein
RMS van den Heuvel <heinvandenheuvel at gmail.com> writes: 

> On Saturday, September 13, 2014 11:03:36 AM UTC-4, Phillip Helbig---undress to reply wrote:
> Philip> Is there a QUICK AND EASY way to detect links which have been produced
> Philip>  via SET FILE/ENTER?
> 
> Yes, kinda.

Thanks; this is what I was looking for.

> As you probably know, SET FILE/ENTER changes NOTHING to the original
> file (header). It only creates a new filename entry in the same, or a
> different directory on the same volume. The file header has the original
> name in there, and a backlink FID to the original directory. 

Right.

> This is how the file system protects you from 'accidentally' deleting
> the original file when deleting an alias, and how it manages RENAMEs. 

> If one just _knows_ that the entry is an alias (eg in build tree,
> sandbox) then I encourage using SET FILE/REMOVE as it is the minimal
> amount of work. 

DELETE is shorter than SET FILE/REMOVE.  :-)

> If one does NOT know, then just use delete and trust the XQP to do the
> right thing. There is now way you can code up a test to do less work
> then the minimal work the XQP does to figure this out. The XQP has all
> the context right there. ( Listings: [xqp]delete.lis, routine
> ALIAS_ENTRY, flag variable PRIMARY ) 

OK, so DELETE will always work, deleting the file I think it will; if 
there are other aliases, then they remain.  At least if I don't delete 
the main entry.

> This is also how you can test whether the file is the original.
> Just compare F$SEARCH output for the file with F$FID output.

Great tip, thanks!

> If they are NOT the same then an alias was used.
> A delete would turn into a REMOVE, a rename only changes the directory
> entry, not the file header. 

OK, so DELETE notices this under the hood and does the right thing.

> $ delete/log RAM:[A]TEST.TXT;1  !Deleting the main file leaves
> dangling aliasses 

But it DOESN'T do the right thing here.

> So as per my advice to Phillip, just use delete, and let OpenVMS
> figure it out. 

Unless I delete the original file!  :-(

So, one can easily check whether a file is actually an alias.  However,
this is not necessary because DELETE will do the right thing anyway. 
(The HELP suggestion to use SET FILE/REMOVE here is then a bit 
confusing.)  However, apparently there is no way to check if the primary 
file has additional entries, at least not without scanning all 
directories on the volume.  This is a shame, since deleting it might 
have bad consequences (dangling aliases) elsewhere.