Deleting alias files (blocks deleted)
JF Mezei
Is it normal when one is deleting an alias file that the delete command
reports having deleted X blocks ?
Shouldn't it report having deleted 0 blocks ?
(This is on VAX VMS 7.2)
David J Dachtera
DELETE will remove the directory entry and $DELETE the file. The
remaining directory entry(-ies) now point(s) to a file that no longer
exists.
You're looking for SET FILE/REMOVE, not DELETE (i.e., there is no
DELETE/ALIAS, AFAIK).
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Coming soon:
Unofficial OpenVMS Marketing Home Page
JF Mezei
> DELETE will remove the directory entry and $DELETE the file. The
> remaining directory entry(-ies) now point(s) to a file that no longer
> exists.
That is terrible.
One of those files was SYSBOOT.EXE, there was an alias in [000000].
The file is still in [VMS$COMMON.SYSEXE] and I can dump it. And
ANA/DISK/REPAIR finds no problem with the disk. Shouldn't it find that
the file in VMS$COMMON points to free blocks ?
Frankly, if DELETE doesn't check the alias bit in the directory entry, I
am terribly disapointed. It doesn't let you delete a non empty directory
file. So you'd expect it to either properly delete an alias entry or not
delete it at all and warn about it.
Is there a garantee that ANA/DISK will spot any inconsistencies due to
my deleteing the alias file but not the main file ? If ANA/DISK doesn't
find anything wrong, does this mean I did not cause any damage ?
Peter 'EPLAN' LANGSTOEGER
>Is it normal when one is deleting an alias file that the delete command
>reports having deleted X blocks ?
>
>Shouldn't it report having deleted 0 blocks ?
It should (in my eyes too), but (AFAIK) it never did so far.
Perhaps an improvement area for Guy...
--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail pe...@langstoeger.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
Peter 'EPLAN' LANGSTOEGER
>JF Mezei wrote:
>> Is it normal when one is deleting an alias file that the delete command
>> reports having deleted X blocks ?
>>
>> Shouldn't it report having deleted 0 blocks ?
>>
>> (This is on VAX VMS 7.2)
>
>DELETE will remove the directory entry and $DELETE the file. The
>remaining directory entry(-ies) now point(s) to a file that no longer
>exists.
But only on VAXes. On Alphas it was fixed long ago and deletes the file
only if this is the last pointer to the file. (It is said to also fix
the backlink pointer FID and the file name in the file header to make
one of the secondary entries to the primary entry if the original entry
gets deleted - but I haven't seen this so far !! - backlink pointer FID
has a random value and file name in file header keeps unchanged)
>You're looking for SET FILE/REMOVE, not DELETE (i.e., there is no
>DELETE/ALIAS, AFAIK).
Be careful.
With SET FILE/REMOVE you can still remove the only/primary
entry and get a lost file then (on Alphas, too).
Hoff/Guy ?
Peter 'EPLAN' LANGSTOEGER
>David J Dachtera wrote:
>> DELETE will remove the directory entry and $DELETE the file. The
>> remaining directory entry(-ies) now point(s) to a file that no longer
>> exists.
>
>That is terrible.
>
>One of those files was SYSBOOT.EXE, there was an alias in [000000].
And which did you delete ? The primary or the secondary ?
Did you check before deleting ? And if not how did you know it was
an alias entry at all ?
>The file is still in [VMS$COMMON.SYSEXE] and I can dump it. And
>ANA/DISK/REPAIR finds no problem with the disk. Shouldn't it find that
>the file in VMS$COMMON points to free blocks ?
If you deleted the primary then a DIRECTORY/mumble (again, on a VAX only)
would give you "no such file" instead of date/security/size. VERIFY would
tell %ANALDISK-W-BADDIRENT, invalid file identification in directory entry
So you obviously deleted the alias and everything is still ok.
>Frankly, if DELETE doesn't check the alias bit in the directory entry, I
There is no "alias bit". Only backlink FID (and file name) makes a
directory entry of a file to the primary or a secondary one.
>am terribly disapointed. It doesn't let you delete a non empty directory
>file. So you'd expect it to either properly delete an alias entry or not
>delete it at all and warn about it.
On OpenVMS VAX it seems you are on your own now.
But you had ~20 years to tell them about bugs and gotta have it fixed.
Do yourself a favor and get a cheap Alpha, test there and only then
you could expect VMS engineering to fix the (still existing) bugs in VMS.
Yes, I would like to see such bug fixes in OpenVMS VAX, too.
But I no longer expect it (and I still really hope, that VMS doesn't die
at all with this Itanic thing)
>Is there a garantee that ANA/DISK will spot any inconsistencies due to
>my deleteing the alias file but not the main file ? If ANA/DISK doesn't
>find anything wrong, does this mean I did not cause any damage ?
Every VMS version did have improvements so far. V7.2 is older/worse than
V7.3 and OpenVMS VAX is older/worse than OpenVMS Alpha and OpenVMS I64.
I have seen VERIFY find no errors when there have been some and I also
have seen VERIFY corrupt the disk during a /REPAIR (long long ago).
So your only guarantee is keep VMS as current as feasible/possible...
AEF
Peter 'EPLAN' LANGSTOEGER wrote:
> In article <43A5EB16...@teksavvy.com>, JF Mezei <jfmezei...@teksavvy.com> writes:
> >Is it normal when one is deleting an alias file that the delete command
> >reports having deleted X blocks ?
> >
> >Shouldn't it report having deleted 0 blocks ?
>
> It should (in my eyes too), but (AFAIK) it never did so far.
> Perhaps an improvement area for Guy...
Without warning that it is an alias entry that is being removed, that
is also misleading.
IMW, BISTM that this whole alias feature was -- at least at first --
just an ad hoc addition as part of the evolution of VMScluster system
disks. Using aliases for other purposes is partly "use at your own
risk" or "as is". This would then be just like the way "default" SET
FILE/NOBACKUP PAGEFILE.SYS,SWAPFILE,SYSDUMP.DMP is an ad hoc way to
speed up system backups. At least one site (I was a user at that site)
tried to use SET FILE/NOBACKUP to make BACKUP "skip" saving a scratch
directory tree. Well, one day the site did a restore and we got the
scratch directory tree back with all the files but no data: not quite
the desired result! I now understand why that happened but it was
confusing then. And it seems to be a similar case with aliases. They're
really not that easy to deal with. Directory doesn't tell you which
files are just aliase entries and other DCL commands don't warn about
any alias entries they encounter. It appears to not have been meant for
"general use".
Just changing (>0) blocks to 0 blocks is not really helpful in my eyes.
Either a warning from hp that you use the alias feature "as is" or a
more comprehensive fix is needed.
AEF
JF Mezei
> And which did you delete ? The primary or the secondary ?
> Did you check before deleting ? And if not how did you know it was
> an alias entry at all ?
MC DFU DIR/ALIAS
(it did report in one run that oen file (a lot file) was its own alias !).
But disk:[000000]SYSBOOT.EXE was clearly an alias of the real file (same
file IDs).
> If you deleted the primary then a DIRECTORY/mumble (again, on a VAX only)
> would give you "no such file" instead of date/security/size. VERIFY would
> tell %ANALDISK-W-BADDIRENT, invalid file identification in directory entry
>
> So you obviously deleted the alias and everything is still ok.
Well it seems. But when folks here reported that I would have actually
deleted data it got me scared.
Coumpound this with the fact that there was a obscure boot flag in the
SRM that wanted it to boot from a non-existant SYS1 and I really though
I had lot the system. Used WRITEBOOT.EXE plenty of times, searched
everywhere.... Eventually clued in on the boot flag.
> There is no "alias bit". Only backlink FID (and file name) akes a
> directory entry of a file to the primary or a secondary one.
I thought that there was in fact an alias bit in the directory file. (or
is it in INDEXF.SYS ?)
> Do yourself a favor and get a cheap Alpha, test there and only then
> you could expect VMS engineering to fix the (still existing) bugs in VMS.
It is pretty obvious that VAX-VMS has been abandonned. I certaintly
can't expect support from the current owner of VMS.
Hence support from this newsgroups :-)
Hoff Hoffman
DELETE checks the directory bit and has done so for six+ major releases
of OpenVMS. If the directory bit is set, the directory file cannot be
deleted until the contents of the directory are deleted.
DELETE does not check the alias bit (and there isn't one of those), it
deletes the file. Prior to recent OpenVMS versions, there was no real
way to check for multiple aliases for a particular file within OpenVMS;
there was no count of aliases around.
For the general case reported, if tracts of the OpenVMS system disk were
deleted, then the system disk is arguably corrupt. Various core parts
of the OpenVMS system disk structure are built on alias entries starting
with the advent of the cluster common system disk -- which around around
V3.x or so and eventually became standard structure for system disk
volumes -- and each root on the cluster common system disk shares
directories with any other root present and with the common root.
Aiming an errant DELETE at a system file or system directory can easily
cause collateral damage, in other words.
If some or all of the core parts of the particular OpenVMS system disk
are now gone, restore from your most recent off-line BACKUP/IMAGE, or
reinstall OpenVMS.
If SYS$SYSDEVICE:[SYSEXE]SYSBOOT.EXE was deleted (or other core OpenVMS
files), ANALYZE/DISK will not show any errors associated with that --
this as ANALYZE/DISK is intended to verify the volume structure and not
the volume contents. You can potentially restore SYSBOOT.EXE to
SYS$COMMON:[SYSEXE]SYSBOOT.EXE (if that was the target for the DELETE
and that file was an alias entry), and you can remove any detritus
associated with the SYS$SYSDEVICE:[SYSEXE]SYSBOOT.EXE entry -- unless
you are using this disk with and have a MicroVAX I or VAXstation I
series system.
It is possible that the entry in SYSBOOT.EXE was long ago removed or the
system disk was once erroneously restored, and that the entry was never
connected when the DELETE arrived. If so, the particular DELETE was
potentially harmless, save for VAX systems using the version of VMB
built into the those few ancient VAX systems that have assumptions of
the V2-vintage "flat" system disk structures. AFAIK, this is only
ancient copies of VMB.EXE found out in equivalently ancient VAX console
media, and maybe the version of VMB found in the MicroVAX I and
VAXstation I KA610/KD32 class processor. Anything circa V3 or later
will look for the common root copy of the SYSBOOT.EXE image and will
boot from there.
Prior to the DELETE of SYS$SYSDEVICE:[SYSEXE]SYSBOOT.EXE, a
DIRECTORY/FILE could have been used to verify the files are different;
that the files are not alias entries based on the displayed FID values.
(Files that are alias entries can and will have the same FID value
when resident on the same disk.)
I would also personally tend to consider removing the privileges of any
user that performed this or similar DELETE on a production OpenVMS
system that I was responsible for, in the most blunt of phrasing.
Evidence of a full off-line system BACKUP/IMAGE made immediately before
any such DELETE activity and/or substantial past evidence of careful
system operations might potentially be applied as evidence to attempt to
soften my initial response of MODIFY /PRIV=(NOALL,TMPMBX,NETMBX)
/DEFPRIV=(NOALL,TMPMBX,NETMBX); in an attempt to dissuade me from a
reaction that would tend to follow such actions as a DELETE aimed at
system-related files on a production system disk. That evidence may or
may not actually prevent my removal of system privileges (within the
production environment) from the user involved, of course. (This is the
"delete system privileges first, and ask questions later" reaction, of
course, and other system managers of production systems may or may not
subscribe to this same approach.)
If this is a hobbyist, non-production, target-practice or a testing
system, well, have at -- a valuable lesson has been learned by some
number of folks involved, and the necessary recovery or re-installation
can now be be commenced. (If this is an isolated copy of SYSBOOT.EXE,
and a current SYSBOOT is still present in the SYS$COMMON:[SYSEXE] area,
then no recovery is required.)
If this was a production OpenVMS system that is now being recovered, I
would also tend to start the recovery with a full off-line BACKUP/IMAGE.
This on the off change that something in the recovery causes
additional problems, and given there is apparently no current archival
copy available.
JF Mezei
> If some or all of the core parts of the particular OpenVMS system disk
> are now gone, restore from your most recent off-line BACKUP/IMAGE, or
> reinstall OpenVMS.
That is the problem ! They are not gone !
DFU DIR/ALIAS said that [000000]SYSBOOT.EXE was an alias for [VMS$COMMON.SYSEXE]SYSBOOT.EXE
I did a DELETE [000000]SYSBOOT.EXE; (thinking it would simply remove the
directory entry). But it indicated it deleted many blocks. However,
[VMS$COMMON.SYSEXE]SYSBOOT.EXE was still there, CHECKSUM produced the
same number as a checksum of SYSBOOT.EXE on a different system disk. And
ANA/DISK revealed no problems.
> If SYS$SYSDEVICE:[SYSEXE]SYSBOOT.EXE was deleted (or other core OpenVMS
> files), ANALYZE/DISK will not show any errors associated with that --
If I deleted [000000]SYSBOOT.EXE, wouldn't ANA/DISK then report that
[VMS$COMMON.SYSEXE]SYSBOOT.EXE is some rogue directory entry ?
Wouldn't any access to the file (COPY, CHECKSUM etc) fail since there
would either not be an INDEXF.SYS entry or there would be one pointing
to free blocks ?
> reaction that would tend to follow such actions as a DELETE aimed at
> system-related files on a production system disk.
It was a DELETE aimed ate cleaning up that 18 year old system disk that
had accumulated lint and had some file entries in [0000000] that didn't
belong there with no recollection of how they got there.
Is there a way to ensure that tbe blocks in
[VMS$COMMON.SYSEXE]SYSBOOT.EXE are in fact allocated to that file and
not blocks that were freed when the alias was deleted and the contents
of that file will eventually change when those blocks are given to some
other file ?
(isn't that what ANA/DISK/REPAIR checks for ?)
AEF
JF Mezei wrote:
> Hoff Hoffman wrote:
> > If some or all of the core parts of the particular OpenVMS system disk
> > are now gone, restore from your most recent off-line BACKUP/IMAGE, or
> > reinstall OpenVMS.
>
>
> That is the problem ! They are not gone !
>
> DFU DIR/ALIAS said that [000000]SYSBOOT.EXE was an alias for [VMS$COMMON.SYSEXE]SYSBOOT.EXE
>
It's a problem that you didn't lose SYSBOOT.EXE?
> I did a DELETE [000000]SYSBOOT.EXE; (thinking it would simply remove the
> directory entry). But it indicated it deleted many blocks. However,
> [VMS$COMMON.SYSEXE]SYSBOOT.EXE was still there, CHECKSUM produced the
> same number as a checksum of SYSBOOT.EXE on a different system disk. And
> ANA/DISK revealed no problems.
I'd be a little more careful before deleting files like SYSBOOT.EXE.
Why are you deleting this? Use SET FILE/REMOVE to remove alias entries.
But it sounds like you WANT to delete SYSBOOT.EXE! Why? Don't you need
that? This is a system disk, right?
>
> > If SYS$SYSDEVICE:[SYSEXE]SYSBOOT.EXE was deleted (or other core OpenVMS
> > files), ANALYZE/DISK will not show any errors associated with that --
>
>
> If I deleted [000000]SYSBOOT.EXE, wouldn't ANA/DISK then report that
> [VMS$COMMON.SYSEXE]SYSBOOT.EXE is some rogue directory entry ?
Only if you deleted the primary entry. That would delete the actual
header and data of the file, leaving an orphaned alias in some .DIR
file. ANAL/DISK would complain about that! But you deleted the alias
and fortunately still have the primary entry along with the data and
file header.
>
> Wouldn't any access to the file (COPY, CHECKSUM etc) fail since there
> would either not be an INDEXF.SYS entry or there would be one pointing
> to free blocks ?
>
> > reaction that would tend to follow such actions as a DELETE aimed at
> > system-related files on a production system disk.
>
> It was a DELETE aimed ate cleaning up that 18 year old system disk that
> had accumulated lint and had some file entries in [0000000] that didn't
> belong there with no recollection of how they got there.
Removing an alias frees up less than one block of disk space. If you
have to resort to deleting important system files to clean up a disk,
how did it ever work with adequate space in the first place?
> Is there a way to ensure that tbe blocks in
> [VMS$COMMON.SYSEXE]SYSBOOT.EXE are in fact allocated to that file and
> not blocks that were freed when the alias was deleted and the contents
> of that file will eventually change when those blocks are given to some
> other file ?
This question makes no sense. If the blocks are there, you've got them.
If you free only an alias, you still have the primary directory entry
which means you also have the file's data and header. And if you remove
the last directory entry via SET FILE/REMOVE, you will still have the
file's data and header which are recoverable by ANAL/DISK/REPAIR.
>
> (isn't that what ANA/DISK/REPAIR checks for ?)
ANAL/DISK doesn't check for a valid system disk. If it finds a
directory entry pointing to a deleted file header, it will report that
and repair it if you ask. If it finds a file header that has no
directory entry, it will report that and optionally repair it, putting
it in [SYSLOST].
If you're going to play with deleting aliases like this, you need to
learn more about how they work. Check the File Applications manual. And
I'd not mess with SYSBOOT.EXE in the first place unless I were really
sure what I was doing.
David J Dachtera
>
> In article <43A62BED...@comcast.net>, David J Dachtera <djesys...@comcast.net> writes:
> >JF Mezei wrote:
> >> Is it normal when one is deleting an alias file that the delete command
> >> reports having deleted X blocks ?
> >>
> >> Shouldn't it report having deleted 0 blocks ?
> >>
> >> (This is on VAX VMS 7.2)
> >
> >DELETE will remove the directory entry and $DELETE the file. The
> >remaining directory entry(-ies) now point(s) to a file that no longer
> >exists.
>
> But only on VAXes. On Alphas it was fixed long ago and deletes the file
> only if this is the last pointer to the file.
Ooohhh... careful, there!
Remember: this "pointers" ("links") bit is new for ODS-5, and is only
true of ODS-5, AFAIK.
> (It is said to also fix
> the backlink pointer FID and the file name in the file header to make
> one of the secondary entries to the primary entry if the original entry
> gets deleted - but I haven't seen this so far !! - backlink pointer FID
> has a random value and file name in file header keeps unchanged)
>
> >You're looking for SET FILE/REMOVE, not DELETE (i.e., there is no
> >DELETE/ALIAS, AFAIK).
>
> Be careful.
> With SET FILE/REMOVE you can still remove the only/primary
> entry and get a lost file then (on Alphas, too).
That has always been true.
The "hard" part is identifying aliases without "turning hand-springs".
Perhaps DIRECTORY/FULL and/or DIRECTORY/ALIAS (new qualifier? - whaddaya
think, Guy?) should include some indication that the directory entry's
back-link FID does not match of the FID of the directory where the entry
was found, in addition to the link count.
David J Dachtera
>
> Hoff Hoffman wrote:
> > If some or all of the core parts of the particular OpenVMS system disk
> > are now gone, restore from your most recent off-line BACKUP/IMAGE, or
> > reinstall OpenVMS.
>
> That is the problem ! They are not gone !
>
> DFU DIR/ALIAS said that [000000]SYSBOOT.EXE was an alias for [VMS$COMMON.SYSEXE]SYSBOOT.EXE
>
> I did a DELETE [000000]SYSBOOT.EXE; (thinking it would simply remove the
> directory entry). But it indicated it deleted many blocks. However,
> [VMS$COMMON.SYSEXE]SYSBOOT.EXE was still there, CHECKSUM produced the
> same number as a checksum of SYSBOOT.EXE on a different system disk. And
> ANA/DISK revealed no problems.
I'd have to wonder what SYSBOOT.EXE was doing in the MFD. Since the file
exists in the expected path, this was likely a garbage file, anyway. If
no blocks are trashed according to ANAL/DISK, you should be o.k.
> [snip]
> It was a DELETE aimed ate cleaning up that 18 year old system disk that
> had accumulated lint and had some file entries in [0000000] that didn't
> belong there with no recollection of how they got there.
--
John Santos
On a VAX? Never! As others have posted, deleting the file by any
of its aliases releases the file header, and deallocates all the
blocks, leaving any other directory entries as dangling pointers to
a deleted file. This has always been true, ever since alias entries
have been possible, VMS V1.0, IIRC. (SET FILE/ENTER and SET FILE/REMOVE
came about *long* before the cluster common directory structure of
V3.7 or so.)
Only on Alpha VMS 7.3(-1?) or later, on an ODS-5 disk with hardlinks
enabled is the above true. Ans AFAIK, it doesn't distinguish the
primary entry from alias entries, it just doesn't delete the file
until the link count goes to zero.
That I agree with :-)
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
Dave Froble
>
> I would also personally tend to consider removing the privileges of any
> user that performed this or similar DELETE on a production OpenVMS
> system that I was responsible for, in the most blunt of phrasing.
> Evidence of a full off-line system BACKUP/IMAGE made immediately before
> any such DELETE activity and/or substantial past evidence of careful
> system operations might potentially be applied as evidence to attempt to
> soften my initial response of MODIFY /PRIV=(NOALL,TMPMBX,NETMBX)
> /DEFPRIV=(NOALL,TMPMBX,NETMBX); in an attempt to dissuade me from a
> reaction that would tend to follow such actions as a DELETE aimed at
> system-related files on a production system disk.
Me thinks that Steve is reaching for the large mallet normally used for
smashing fingers, and in extreme cases, flattens the top of heads. :-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. Fax: 724-529-0596
DFE Ultralights, Inc. E-Mail: da...@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
> Hoff Hoffman wrote:
>
>>If some or all of the core parts of the particular OpenVMS system disk
>>are now gone, restore from your most recent off-line BACKUP/IMAGE, or
>>reinstall OpenVMS.
>
>
>
> That is the problem ! They are not gone !
>
> DFU DIR/ALIAS said that [000000]SYSBOOT.EXE was an alias for [VMS$COMMON.SYSEXE]SYSBOOT.EXE
My recolection is that VMS$COMMON is the primary directory structure for
the VMS files, and the others are the alias directories. Still, many
references are to the alias directories. Seems reasonable to me.
> I did a DELETE [000000]SYSBOOT.EXE; (thinking it would simply remove the
> directory entry). But it indicated it deleted many blocks. However,
> [VMS$COMMON.SYSEXE]SYSBOOT.EXE was still there, CHECKSUM produced the
> same number as a checksum of SYSBOOT.EXE on a different system disk. And
> ANA/DISK revealed no problems.
As Steve stated, that is NOT the purpose of ANA/DISK!
>>If SYS$SYSDEVICE:[SYSEXE]SYSBOOT.EXE was deleted (or other core OpenVMS
>>files), ANALYZE/DISK will not show any errors associated with that --
>
>
>
> If I deleted [000000]SYSBOOT.EXE, wouldn't ANA/DISK then report that
> [VMS$COMMON.SYSEXE]SYSBOOT.EXE is some rogue directory entry ?
See above.
> Wouldn't any access to the file (COPY, CHECKSUM etc) fail since there
> would either not be an INDEXF.SYS entry or there would be one pointing
> to free blocks ?
>
>
>>reaction that would tend to follow such actions as a DELETE aimed at
>>system-related files on a production system disk.
>
>
> It was a DELETE aimed ate cleaning up that 18 year old system disk that
> had accumulated lint and had some file entries in [0000000] that didn't
> belong there with no recollection of how they got there.
When doing so, one assumes the responsibility of knowing EXACTLY what
one is doing, and any errors/mistakes are solely attributed to the guilty.
> Is there a way to ensure that tbe blocks in
> [VMS$COMMON.SYSEXE]SYSBOOT.EXE are in fact allocated to that file and
> not blocks that were freed when the alias was deleted and the contents
> of that file will eventually change when those blocks are given to some
> other file ?
>
> (isn't that what ANA/DISK/REPAIR checks for ?)
I'm not sure that you have a problem, nor can I say you don't. From a
V7.2 VAX system, user directories removed from the list:
Directory SYS$SYSDEVICE:[000,000]
000000.DIR;1 2/2 [1,1] (RWED,RWED,RE,E)
BACKUP.DIR;1 1/1 [BACKUP] (RWE,RWE,RE,E)
BACKUP.SYS;1 0/0 [1,1] (RWED,RWED,RE,)
BADBLK.SYS;1 0/0 [1,1] (RWED,RWED,RE,)
BADLOG.SYS;1 0/0 [1,1] (RWED,RWED,RE,)
BITMAP.SYS;1 512/512 [1,1] (RWED,RWED,RE,)
CONTIN.SYS;1 0/0 [1,1] (RWED,RWED,RE,)
CORIMG.SYS;1 0/0 [1,1] (RWED,RWED,RE,)
.
.
.
INDEXF.SYS;1 9831/40066 [1,1] (RWED,RWED,RE,)
SECURITY.SYS;1 1/1 [1,1] (RWED,RWED,RE,)
SYS0.DIR;1 1/1 [SYSTEM] (RWE,RWE,RE,RE)
SYSE.DIR;1 1/1 [1,1] (RWE,RWE,RE,E)
SYSEXE.DIR;1 1/1 [SYSTEM] (R,R,,)
SYSMAINT.DIR;1 1/1 [SYSTEM] (RWE,RWE,RE,RE)
TCPIP$FINGER.DIR;1 1/1 [TCPIP$AUX (RWE,RWE,RE,E)
TCPIP$FTP.DIR;1 1/1 [TCPIP$AUX (RWE,RWE,RE,E)
TCPIP$ROUTED.DIR;1 1/1 [SYSTEM] (RWE,RWE,RE,E)
TCPIP$TFTP.DIR;1 1/1 [TCPIP$AUX (RWE,RWE,RE,E)
TCPIP$TFTP_ROOT.DIR;1 1/1 [TCPIP$AUX (RWE,RWE,RE,E)
VMS$COMMON.DIR;1 3/3 [SYSTEM] (RWE,RWE,RE,RE)
VOLSET.SYS;1 0/0 [1,1] (RWED,RWED,RE,)
I don't see SYSBOOT in [0,0]. If your system is still booting
successfully and not showing any problems, maybe you're Ok. If you
haven't re-booted yet, a good backup of anything you want is advised.
Maybe since you're having fun with your new systems, now might be the
time to do a fresh install of VMS and then a restore of whatever you
wish to retain. That's the only foolproof method I know to clear out
old lint and cruft.
AEF
John Santos wrote:
> AEF wrote:
> > JF Mezei wrote:
> >
> >>If I deleted [000000]SYSBOOT.EXE, wouldn't ANA/DISK then report that
> >>[VMS$COMMON.SYSEXE]SYSBOOT.EXE is some rogue directory entry ?
> >
> >
> > Only if you deleted the primary entry. That would delete the actual
> > header and data of the file, leaving an orphaned alias in some .DIR
> > file. ANAL/DISK would complain about that! But you deleted the alias
> > and fortunately still have the primary entry along with the data and
> > file header.
> >
>
> On a VAX? Never! As others have posted, deleting the file by any
Yes.
> of its aliases releases the file header, and deallocates all the
> blocks, leaving any other directory entries as dangling pointers to
> a deleted file.
Not on my VAX systems!
Example (run on VAX/VMS v6.1):
$ TYPE A.A
A.A
$ DIREC/FILE
Directory DISK$DATA1:[FELDMAN.DCL.A]
A.A;1 (44834,5,0)
Total of 1 file.
$ TYPE A.A
A.A
$ SET FILE A.A/ENTER=B.B
$ DIREC/FILE
Directory DISK$DATA1:[FELDMAN.DCL.A]
A.A;1 (44834,5,0)
B.B;1 (44834,5,0)
Total of 2 files.
$ DEL B.B;
%DELETE-I-FILDEL, DISK$DATA1:[FELDMAN.DCL.A]B.B;1 deleted (4 blocks)
$ DIREC/FILE
Directory DISK$DATA1:[FELDMAN.DCL.A]
A.A;1 (44834,5,0)
Total of 1 file.
$ TYPE A.A
A.A
$
> This has always been true, ever since alias entries
> have been possible, VMS V1.0, IIRC. (SET FILE/ENTER and SET FILE/REMOVE
> came about *long* before the cluster common directory structure of
> V3.7 or so.)
Interesting. (I did qualify my statement with ISTM.) For what purpose?
They're a pain to keep track of.
>
> Only on Alpha VMS 7.3(-1?) or later, on an ODS-5 disk with hardlinks
> enabled is the above true. Ans AFAIK, it doesn't distinguish the
> primary entry from alias entries, it just doesn't delete the file
> until the link count goes to zero.
But on my VAX systems, deleting any alias leaves the file alone as you
can see above. Deleting the primary entry leaves dangling alias
entries.
Dave Froble
I don't think you're 'getting it'. If I read what you posted correctly,
A.A and B.B are both files in directory [FELDMAN.DCL.A]. What's being
discussed, if I understand it correctly, is having file A.A in directory
[FELDMAN.DCL.A], and having another directory for the exact same file in
directory [FELDMAN.DCL.B] also. Then, regardless which file you delete,
[FELDMAN.DCL.A]A.A or [FELDMAN.DCL.B]A.A will result in the directory
entry and file being deleted, and leaving a directory entry in the other
directory without a coresponding file.
John Santos
Ugh! I took the radical step of actually trying it. It does seem to
work exactly as Alan says, whether the files are in different
directories or the same directory. (VAX V7.3 and Alpha V7.3-2 on ODS-2
disks.)
I think this must be one of those new-fangled V5.5 features, because
I couldn't find any mention of it in the V6.2 or V7.x Release Notes
or New Features books.
Phillip Helbig---remove CLOTHES to reply
"AEF" <spamsi...@yahoo.com> writes:
I see the same behaviour on 7.3 VAX and 7.3-2 ALPHA.
I seem to remember something about the behaviour depending on whether
the "real" file or the alias is first alphabetically. Test at your own
risk!
JF Mezei
> But on my VAX systems, deleting any alias leaves the file alone as you
> can see above. Deleting the primary entry leaves dangling alias
> entries.
On my VAX, the behaviour seems to match your opinion, but goes against
whate everyone else has been saying.
And I am tryuly sorry if I didn't remember that obscure SET FILE/REMOVE
command which is so seldom used that one can't be expected to remember
100% of the time. You seem, coming from a MAC background, alias files
have always been treated safely with the same "delete" procedure (throw
in the trash) as the master file without ever having to worry about
deleting the alias actually deleting the real file. I think even windows
has that intelligent behaviour and frankly, I can't understand why VMS
couldn't either.
if DFU DIR/ALIAS is able to spot an alias file, why can't DELETE ?
Also, if I have an alias CHOOCOLATE.DAT pointing to VANILLA.DAT, when I
issue the DELETE CHOCOLATE.DAT, woudln't DETELE then lookup the file ID
in INDEXF.SYS and in that record, see that the filename is VANILLA.DAT
and then know that CHOCOLATE.DAT is just an alias which means that the
only operation needed is to remove the CHOCOLATE.DAT from the directory
file containing it ?
Note: the MAC has had this capability since the mid 1980s.
I certaintly didn't create the [000000]SYSBOOT.EXE alias. It must have
happened as part of some upgrade at one point in time, or perhaps as a
result of ANA/DISK/REPAIR or whatever. I also recall that BACKUP at one
point woudln't recreate a system disk properly, requiring system
managers to fiddle with some of the alias entry files (I think that
[SYS0]SYSCOMMON.DIR was the real file and [000000]VMS$COMMON.DIR was an
alias (when it should be the other way around).
Bob Koehler
> Hoff Hoffman wrote:
>> If some or all of the core parts of the particular OpenVMS system disk
>> are now gone, restore from your most recent off-line BACKUP/IMAGE, or
>> reinstall OpenVMS.
>
>
> That is the problem ! They are not gone !
>
> DFU DIR/ALIAS said that [000000]SYSBOOT.EXE was an alias for [VMS$COMMON.SYSEXE]SYSBOOT.EXE
>
VMS dos not normally keep SYSBOOT.EXE in [000000]. I'm begining to
wonder what DFU uses to determine that a file is an alias. IIRC if
both the DID and the file name in the header match the directory and
directory entry then it is the original entry.
Bob Koehler
> I would also personally tend to consider removing the privileges of any
> user that performed this or similar DELETE on a production OpenVMS
> system that I was responsible for, in the most blunt of phrasing.
We knew a "system manager" who deleted a system root by way of
$delete [SYSx...]*.*;* and clobbered much of [VMS$COMMON]. This
was a pre-production system, we were the development contractor and
he worked for the operations contractor.
Guess what he spent his evening doing.
This is from the same team that defined READ:==EDIT/READ and then
couldn't run SHUTDOWN.COM. The customer came to depend on us.
Albrecht Schlosser
>
> Also, if I have an alias CHOOCOLATE.DAT pointing to VANILLA.DAT, when I
> issue the DELETE CHOCOLATE.DAT, woudln't DETELE then lookup the file ID
> in INDEXF.SYS and in that record, see that the filename is VANILLA.DAT
> and then know that CHOCOLATE.DAT is just an alias which means that the
> only operation needed is to remove the CHOCOLATE.DAT from the directory
> file containing it ?
I'd guess, no. First of all, the filename might be the same, but much
more important (IMHO):
what about all the files in [SYS0.SYSEXE] or (e.g.) some subdirectory of
this: There is only one real file, but the directory SYSEXE is an alias!
and what if there are more directory levels? ...
Albrecht
JF Mezei
> what about all the files in [SYS0.SYSEXE] or (e.g.) some subdirectory of
> this: There is only one real file, but the directory SYSEXE is an alias!
Actually, this doesn't matter. It is the directory file which is an
alias.
So when you delete [SYS0.SYSCOMMON.SYSHLP]HELPLIB.HLB , you are not only
freeing the blocks for the .HLP file, but you are also removing a record
from the .DIR file.
And when DELETE is accessing [SYS0.SYSCOMMON]SYSHLP.DIR to remove the
record, it is actually accessing [VMS$COMMON]SYSHLP.DIR.
DIR/FILE confirms this.
AEF
JF Mezei wrote:
> AEF wrote:
> > But on my VAX systems, deleting any alias leaves the file alone as you
> > can see above. Deleting the primary entry leaves dangling alias
> > entries.
>
> On my VAX, the behaviour seems to match your opinion, but goes against
> whate everyone else has been saying.
"Seems"? It's not "seems"; it "does". Why is everyone so reluctant to
acknowledge that I was right?
> And I am tryuly sorry if I didn't remember that obscure SET FILE/REMOVE
> command which is so seldom used that one can't be expected to remember
> 100% of the time. You seem, coming from a MAC background, alias files
> have always been treated safely with the same "delete" procedure (throw
> in the trash) as the master file without ever having to worry about
> deleting the alias actually deleting the real file. I think even windows
> has that intelligent behaviour and frankly, I can't understand why VMS
> couldn't either.
Actually, on second thought, DELETE also works. It removes the alias
and leaves the primary in place. When it says 3 blocks deleted or some
other positive number the number of blocks that will be reported by
DIRECTORY will be that much less. DELETE is a little more dangerous in
that if what you think is an alias is in fact the primary directory
entry, your file is toast and any aliases for that file end up
"dangling".
I am not familar with "aliases" on the Mac, but I don't know what
aliases you refer to on Windows. Are you talking about Windows
"shortcut icons"? Those are not file aliases. They are files that point
to the "primary" file. The parallel in VMS would be a DCL file that
contains
$ @blah.com
which is not an alias. Please clarify what you mean by "aliases".
>
> if DFU DIR/ALIAS is able to spot an alias file, why can't DELETE ?
DELETE does do that and only removes alias entries. The primary entry,
the file header, and the file data remain intact.
> Also, if I have an alias CHOOCOLATE.DAT pointing to VANILLA.DAT, when I
> issue the DELETE CHOCOLATE.DAT, woudln't DETELE then lookup the file ID
> in INDEXF.SYS and in that record, see that the filename is VANILLA.DAT
> and then know that CHOCOLATE.DAT is just an alias which means that the
> only operation needed is to remove the CHOCOLATE.DAT from the directory
> file containing it ?
It does.
> Note: the MAC has had this capability since the mid 1980s.
Are these MAC "aliases" like Windows shortcuts, or true aliases?
Aliases on VMS are not a user-friendly feature. That's why I thought
they were introduced in an ad hoc manner for cluster system disks. But
another poster tells me that VMS aliases pre-date clusters. OK. But
they are not user-friendly. The manual even warns you to be careful
with SET FILE/ENTER and SET FILE/REMOVE (or it warns you about at least
one of them). Mainly, there is nothing in DIRECTORY output that tells
you a file is an alias. You have to scan all directories on a disk to
do that, so I think that's asking a bit much of basic file-handling
commands like DELETE. Think how long a simple DELETE command would take
to execute if it had to scan all .DIR files on the disk! I suppose you
could create an alias database for each disk, but that hasn't been
done. Aliases as they exist today are certainly not meant for casual
use.
> I certaintly didn't create the [000000]SYSBOOT.EXE alias. It must have
> happened as part of some upgrade at one point in time, or perhaps as a
> result of ANA/DISK/REPAIR or whatever. I also recall that BACKUP at one
> point woudln't recreate a system disk properly, requiring system
> managers to fiddle with some of the alias entry files (I think that
> [SYS0]SYSCOMMON.DIR was the real file and [000000]VMS$COMMON.DIR was an
> alias (when it should be the other way around).
Also, I can see why you want to clean up this entry: not to clear up
disk space but to reduce the clutter of unneeded directory entries. OK.
AEF
> Dave Froble wrote:
> > AEF wrote:
> >
> >> John Santos wrote:
> >>
> >>> AEF wrote:
> >>>
> >>>> JF Mezei wrote:
> >>>>
> >>
> >> [...]
> >>
> >>>>> If I deleted [000000]SYSBOOT.EXE, wouldn't ANA/DISK then report that
> >>>>> [VMS$COMMON.SYSEXE]SYSBOOT.EXE is some rogue directory entry ?
> >>>>
> >>>>
> >>>>
> >>>> Only if you deleted the primary entry. That would delete the actual
> >>>> header and data of the file, leaving an orphaned alias in some .DIR
> >>>> file. ANAL/DISK would complain about that! But you deleted the alias
> >>>> and fortunately still have the primary entry along with the data and
> >>>> file header.
> >>>>
> >>>
> >>> On a VAX? Never! As others have posted, deleting the file by any
> >>
> >>
> >>
> >> Yes.
> >>
> >>
> >> But on my VAX systems, deleting any alias leaves the file alone as you
> >> can see above. Deleting the primary entry leaves dangling alias
> >> entries.
> >>
> >
> > I don't think you're 'getting it'. If I read what you posted correctly,
> > A.A and B.B are both files in directory [FELDMAN.DCL.A]. What's being
> > discussed, if I understand it correctly, is having file A.A in directory
> > [FELDMAN.DCL.A], and having another directory for the exact same file in
> > directory [FELDMAN.DCL.B] also. Then, regardless which file you delete,
> > [FELDMAN.DCL.A]A.A or [FELDMAN.DCL.B]A.A will result in the directory
> > entry and file being deleted, and leaving a directory entry in the other
> > directory without a coresponding file.
> Ugh! I took the radical step of actually trying it. It does seem to
^^^^__________________________________________________________^^^^
> work exactly as Alan says, whether the files are in different
> directories or the same directory. (VAX V7.3 and Alpha V7.3-2 on ODS-2
> disks.)
Well,
EEEEXXXXXXXXCCCCCCCCCCUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUSSSSSSSSSSSSEEEEEE
MMMMMMMMEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
for being right! Why is this such a big deal? Especially when it takes
less than 5 min. to check?
Did I commit some great crime in cov? I am often accused of wrongdoing
I didn't do. So I'm not really that upset. And it DOES, not SEEMS to
do.
When I am wrong I not only admit it (well, usually) but if I am the one
to discover that I am wrong I go thru great pains to post a correction.
Hey, sometimes I'm right! &-)
> I think this must be one of those new-fangled V5.5 features, because
> I couldn't find any mention of it in the V6.2 or V7.x Release Notes
> or New Features books.
I was right about the fifth force!
AEF
AEF
I think what DFU does is to first scan all directories and make a
table. Then it looks for directory entries that don't match the names
in the file headers to which they point. Those are considered aliases.
I noticed a new oddity: If you have B.B as an alias for A.A, then SET
FILE/REMOVE A.A;!, you have only an alias left (B.B) which DFU reports
as an alias for []A.A. But if you then DELETE B.B, delete really
deletes it (and it cannot be recovered with ANAL/DISK) even though the
filename in the file header doesn't match the name in the directory.
(Checked on VAX/VMS 6.2)
JF Mezei
> Did I commit some great crime in cov? I am often accused of wrongdoing
> I didn't do. So I'm not really that upset. And it DOES, not SEEMS to
> do.
When some VMS engineer speaks, people listen.
In this case, it appears some VMS engineers need to take a peek at
DELETE.EXE source code to see if there is code to handle alias entries.
AEF
JF Mezei wrote:
> AEF wrote:
> > Did I commit some great crime in cov? I am often accused of wrongdoing
> > I didn't do. So I'm not really that upset. And it DOES, not SEEMS to
> > do.
>
> When some VMS engineer speaks, people listen.
I see. So you try it for yourself and see what it does, but you don't
believe your own eyes until it can be confirmed by a VMS engineer.
> In this case, it appears some VMS engineers need to take a peek at
> DELETE.EXE source code to see if there is code to handle alias entries.
If you try my posted examples examples you'll see that there is. It
obviously doesn't do what YOU would like it to, but that is not yours
to decide. My examples prove that DELETE knows about aliases. Learn how
aliases work; learn how DELETE works; learn how directories and the
index file work; and be sure you have a good backup in case you screw
something up.
JF Mezei
Create a 100k block file DISK:[CAKE]A.A
SET FILE DISK:[CAKE]A.A/enter=DISK:[000000]B.B
SHOW DEV DISK
DELET/LOG [000000]B.B;
SHOW DEV DISK
DELETE says it has deleted 100k blocks. But Show DEV does not change the
amount of free space on the disk.
another test:
$CREATE [CAKE]A.A;
$SET FILE/REMOVE [CAKE]A.A
$ANA/DISK/REPAIR
it does find "ANALDISK-W-LOSTHEADER file (fileid) A.A;1
not found in a directory
and places it in [SYSLOST]
One more test to corroborate what AEF has said:
$CREATE [CAKE]A.A (with allocation of 100k blocks)
$SET FILE [CAKE]A.A /ENTER=[000000]B.B
$SET FILE/REMOVE [CAKE]A.A
$DELETE [000000]B.B
This time, SHOW DEV DISK does show that 100k blocks were freed with the
delete command.
This is with VAX VMS 7.2
What is intertesting in the HELP for SET FILE/NETER is that it cautions
not to create an alias in the same directory as the real file.
Hein RMS van den Heuvel
Still, it is not all that hard to figure out what VMS can / cannot do
in this space.
1) Directory entries point to file headers.
2) For Aliased files, multiple directory entries point to the same
header.
3) Each file header has one, and only one, directory backlink
If a delete is executed on a file which is an alias in an other
directory, then the system can follow that one backlink, determine
there still is a valid entry for the file in the backlinked directory
(yes thise requires and scan of that directory) and magically convert
the delete into a set file/remove operation. This is not part of the
delete utility, but part of the file system. So the deleting tool does
not know this happened, and just reports "x blocks deleted" as always.
If file is deleted through the name which backlinks to itself, then a
real delete is done. Without a 'link count' I'm sure you would not want
the system to then exhaustively search all other directories so see
whether there was an alias somewhere.. for every delete. So poof the
file goes, leaving orphan's behind.
Now if one does a $set file/remove on the directory entry in the
directory for the backlink, then this remove will blank the backlink.
Now a delete through any other alias can no longer determine whether
there are siblings, and becomes a real delete, again leaving other
alias entries as as orphans.
hope this helps,
Hein.
AEF
Correction: The above works for the case in which the file is aliased
in the same directory as the primary entry, but not when the alias has
the same name as the primary, but resides in a different directory.
Then Hein's explanation kicks in, namely, checking if the backlink
matches the directory. If it doesn't, it's an alias!
So you are correct. Your explanation actually covers both cases! I
assume by DID you mean the back link file id.
John Santos
> JF Mezei wrote:
>
>>AEF wrote:
>>
>>>Did I commit some great crime in cov? I am often accused of wrongdoing
>>>I didn't do. So I'm not really that upset. And it DOES, not SEEMS to
>>>do.
>>
>>When some VMS engineer speaks, people listen.
>
>
> I see. So you try it for yourself and see what it does, but you don't
> believe your own eyes until it can be confirmed by a VMS engineer.
>
>
>>In this case, it appears some VMS engineers need to take a peek at
>>DELETE.EXE source code to see if there is code to handle alias entries.
>
I think someone from VMS engineering posted that it worked the way I
*thought* it worked, but couldn't swear to it. However lots of long
time VMS users also said the same thing. Hein has since posted what it
really does, which all makes sense.
> If you try my posted examples examples you'll see that there is. It
> obviously doesn't do what YOU would like it to, but that is not yours
> to decide. My examples prove that DELETE knows about aliases. Learn how
> aliases work; learn how DELETE works; learn how directories and the
> index file work; and be sure you have a good backup in case you screw
> something up.
>
Actually, I think it did exactly what JF would want, namely saved his
butt!
And I did learn how aliases work, and DELETE, and the index file and
directories, long about 1978. Unfortunately for us narrow-minded VMS
bigots something changed.
P.S. The "seems to work the way Alan said" had an implied smiley.
P.P.S. I think the Alias entry for SYSBOOT had something to do with
booting 11/750's or 11/730's (or MicroVAX I?), which had VMB.EXE in
ROM and couldn't cope with the modern system tree-structured directory.
I think it appeared about VMS V4.0. One of my system disks has a
[0,0]SYSEXE.DIR (empty) dating from 24-Mar-1986. I believe at one time
it had an alias entry for SYSBOOT.EXE in it. I can no longer remember
if the file JF deleted was [000000]SYSBOOT.EXE or [SYSEXE]SYSBOOT.EXE.
AEF
Hein RMS van den Heuvel wrote:
> Admittedly the 'X blocks' deleted is confusing.
>
> Still, it is not all that hard to figure out what VMS can / cannot do
> in this space.
>
> 1) Directory entries point to file headers.
> 2) For Aliased files, multiple directory entries point to the same
> header.
> 3) Each file header has one, and only one, directory backlink
>
> If a delete is executed on a file which is an alias in an other
> directory, then the system can follow that one backlink, determine
> there still is a valid entry for the file in the backlinked directory
> (yes thise requires and scan of that directory) and magically convert
> the delete into a set file/remove operation. This is not part of the
> delete utility, but part of the file system. So the deleting tool does
> not know this happened, and just reports "x blocks deleted" as always.
How can it be part of the file system? The file system actively kicks
in to prevent DELETE from marking the file header as not in use?
>
> If file is deleted through the name which backlinks to itself, then a
> real delete is done. Without a 'link count' I'm sure you would not want
> the system to then exhaustively search all other directories so see
> whether there was an alias somewhere.. for every delete. So poof the
> file goes, leaving orphan's behind.
>
> Now if one does a $set file/remove on the directory entry in the
> directory for the backlink, then this remove will blank the backlink.
> Now a delete through any other alias can no longer determine whether
> there are siblings, and becomes a real delete, again leaving other
> alias entries as as orphans.
>
> hope this helps,
> Hein.
>
So, in summary:
When deleting a file, first a check is made to see if the file is the
primary entry. This is done by checking the "back link file id" and
"file name" in the file header. If these match the directory and
filename given to the DELETE command, it is primary and the file is
"really deleted" leaving orphan aliases if any. If it is found not to
be primary, i.e. an alias, then a search is done for the primary. If
the primary is found, a "SET FILE/REMOVE" is done on the alias. If not,
the file is "really deleted".
[...]
Bill Todd
...
> "Seems"? It's not "seems"; it "does". Why is everyone so reluctant to
> acknowledge that I was right?
It's a somewhat understandable (though hardly rational) reaction to
someone who is occasionally something of an asshole, even (or perhaps
especially) when he is wrong (since you asked).
...
> Actually, on second thought, DELETE also works. It removes the alias
> and leaves the primary in place. When it says 3 blocks deleted or some
> other positive number the number of blocks that will be reported by
> DIRECTORY will be that much less.
But since the blocks were not in fact *actually* deleted, it is still
erroneous (unless one accepts a rather contorted definition of 'deleted').
...
> I am not familar with "aliases" on the Mac,
Neither am I, but my guess is (especially in later Mac OS versions) that
they're the same as Unix 'hard links'. Hard links are arguably VMS
aliases done right (or at least as right as they can be done): they
incorporate a reference count such that the actual file sticks around
until the last remaining hard link (directory entry) to the file is
removed, at which point the file itself is deleted as well.
But there's still no good (read: arbitrarily scalable) way to handle
quotas (I'm not going to go down that moderately complex rat-hole: you
can take my word for it or work it out yourself), nor to avoid letting
someone link to a file for which they don't have delete privilege and
then get stuck with it after all other links to it have been removed.
but I don't know what
> aliases you refer to on Windows. Are you talking about Windows
> "shortcut icons"? Those are not file aliases. They are files that point
> to the "primary" file. The parallel in VMS would be a DCL file that
> contains
>
> $ @blah.com
>
> which is not an alias. Please clarify what you mean by "aliases".
Perhaps the NTFS facility that's essentially identical IIRC to Unix hard
links ('shortcuts' are essentially equivalent to Unix 'soft links',
which are sometimes called 'symbolic links').
...
> Aliases on VMS are not a user-friendly feature.
Indeed. Unix hard links are at least fairly user-friendly, even though
they make system features like quotas awkward.
That's why I thought
> they were introduced in an ad hoc manner for cluster system disks. But
> another poster tells me that VMS aliases pre-date clusters.
Actually, they pre-date VMS itself: ODS-1 on RSX had Enter/Remove
facilities that could be used to create aliases.
...
there is nothing in DIRECTORY output that tells
> you a file is an alias. You have to scan all directories on a disk to
> do that, so I think that's asking a bit much of basic file-handling
> commands like DELETE. Think how long a simple DELETE command would take
> to execute if it had to scan all .DIR files on the disk!
If DELETE can determine not to delete the actual file because the link
is an alias, then clearly the information is available (and is available
to DIRECTORY as well: it just doesn't bother to report it).
Hoff already mentioned that there is no 'alias flag', so I'll describe
my very vague recollection of how this works and let anyone with more
recent (or more solid) information correct it if necessary.
ODS-1 worked the way some people here thought ODS-2 worked: a DELETE
operation through *any* link would delete the actual file contents and
leave any other links dangling, because in ODS-1 there was no way to be
sure whether a link was the original one or an alias. In particular,
the RENAME operation did not reliably update the name in the file's
header, so that was not a reliable indicator (and the file header did
not contain the FID of the directory in which the file was originally
created, either - so an alias with the same name in another directory
would have confused matters anyway).
ODS-2 both included the FID of the parent directory containing the
'primary' link and updated the name in the file header on RENAME
(presumably only when the file was RENAMEd through the 'primary' link),
and presumably changed the parent-directory FID if the file was RENAMEd
through the primary link to another directory. So the combination was
sufficient to ascertain whether a directory entry was an alias or not -
as long as no one screwed around manually with those header fields.
This does not, however, explain the sequence where an alias was created,
the original link REMOVEd, and then the file successfully DELETEd via
the alias. Perhaps DELETE through an alias checks for the existence of
the primary link and if not present figures that it had better get rid
of the file as well as the alias (just in case it's the *last* alias).
- bill
Bill Todd
...
> Hoff already mentioned that there is no 'alias flag', so I'll describe
> my very vague recollection of how this works and let anyone with more
> recent (or more solid) information correct it if necessary.
Ah - through the magic of Usenet propagation latency it seems that Hein
had already stepped up to the plate. At least the quality of my
recollections and guesses didn't prove unduly embarrassing.
- bill
JF Mezei
Many thanks for the explanation.
> Now if one does a $set file/remove on the directory entry in the
> directory for the backlink, then this remove will blank the backlink.
> Now a delete through any other alias can no longer determine whether
> there are siblings, and becomes a real delete, again leaving other
> alias entries as as orphans.
so SET FILE/REMOVE on a real file will actually update INDEXF.SYS's
record for that file-ID ?
Based on your explanation prevous to that paragraph, I would have
thought that it would only play with the directory file and not touch
INDEXF.SYS. Then, when you do a DELETE on the alias, the system would
realise that the backlink in INDEXF.SYS is no longer valid and act as a
real delete.
AEF
Bill Todd wrote:
> AEF wrote:
>
> ...
>
> > "Seems"? It's not "seems"; it "does". Why is everyone so reluctant to
> > acknowledge that I was right?
>
> It's a somewhat understandable (though hardly rational) reaction to
> someone who is occasionally something of an asshole, even (or perhaps
> especially) when he is wrong (since you asked).
Look who's talking.
[...]
> ODS-2 both included the FID of the parent directory containing the
> 'primary' link and updated the name in the file header on RENAME
> (presumably only when the file was RENAMEd through the 'primary' link),
> and presumably changed the parent-directory FID if the file was RENAMEd
> through the primary link to another directory. So the combination was
> sufficient to ascertain whether a directory entry was an alias or not -
> as long as no one screwed around manually with those header fields.
>
> This does not, however, explain the sequence where an alias was created,
> the original link REMOVEd, and then the file successfully DELETEd via
> the alias. Perhaps DELETE through an alias checks for the existence of
> the primary link and if not present figures that it had better get rid
> of the file as well as the alias (just in case it's the *last* alias).
Perhaps you didn't read the other posts that explains this just fine.
>
> - bill
JF Mezei
> Neither am I, but my guess is (especially in later Mac OS versions) that
> they're the same as Unix 'hard links'. Hard links are arguably VMS
> aliases done right (or at least as right as they can be done): they
> incorporate a reference count such that the actual file sticks around
> until the last remaining hard link (directory entry) to the file is
> removed,
Not in MAC OS Classic. YOu could have aliases pointing to non existent
files. When you try to access it, the OS puts up a dialog and gives you
the chance to find the original file and reset the link to it.
Hein RMS van den Heuvel
AEF... the variant with the same file being entered in a directory
twice was discussed already I taught on (too) quick reading
JF,
"so SET FILE/REMOVE on a real file will actually update INDEXF.SYS's
record for that file-ID ?"
Yes. Takes less than 5 minutes to try:
$ cop nl: [.a]x.x
$ set file/ent=[.b] [.a]x.x
$ dir/file a.dir,b,[.%]x.x
$ dir/file a.dir,b,[.%]x.x/nohead/notrai/wid=fil=45
EISNER$DRA3:[DECUSERVE_USER.HEIN]A.DIR;1 (26735,303,0)
EISNER$DRA3:[DECUSERVE_USER.HEIN]B.DIR;1 (28211,583,0)
EISNER$DRA3:[DECUSERVE_USER.HEIN.A]X.X;1 (38219,1299,0)
EISNER$DRA3:[DECUSERVE_USER.HEIN.B]X.X;1 (38219,1299,0)
$ pipe dump/head/bloc=coun=0 [.%]x.x | sea sys$pipe "file ident"
File identification: (38219,1299,0)
Extension file identification: (0,0,0)
Back link file identification: (26735,303,0)
File identification: (38219,1299,0)
Extension file identification: (0,0,0)
Back link file identification: (26735,303,0)
$ set file/remo [.a]x.x.
$ pipe dump/head/bloc=coun=0 [.%]x.x | sea sys$pipe "file ident"
File identification: (38219,1299,0)
Extension file identification: (0,0,0)
Back link file identification: (0,0,0)
"when you do a DELETE on the alias, the system would
realise that the backlink in INDEXF.SYS is no longer valid and act as a
real delete."
Yes, pretty much.
The back link itself might point to a valid directory, but if that file
id does not live in a directory record in that directory, then it is
believed invalid, and the file deleted.
This is slightly trickier to arrange, and set file/remove updates the
backlink.
But witness:
and certainly imho not worth the effort,
$ set file/ente=[.a] [.b]x.x
$ dir/file a.dir,b,[.%]x.x/nohead/notrai/wid=fil=45
EISNER$DRA3:[DECUSERVE_USER.HEIN]A.DIR;1 (26735,303,0)
EISNER$DRA3:[DECUSERVE_USER.HEIN]B.DIR;1 (28211,583,0)
EISNER$DRA3:[DECUSERVE_USER.HEIN.A]X.X;1 (38219,1299,0)
EISNER$DRA3:[DECUSERVE_USER.HEIN.B]X.X;1 (38219,1299,0)
$! Notice how the new directory is picked up, not the new old [.b]
$ pipe dump/head/bloc=coun=0 [.%]x.x | sea sys$pipe "back link"
Back link file identification: (26735,303,0)
Back link file identification: (26735,303,0)
$ open/read/write a a.dir
$ read a rec
$ write sys$output %x10000+f$cvsi(10*8,2*8,rec)
38219
$ rec[10*8,2*8]=12345
$ write/update a rec
$ close a
$ dir/file [.%]x.x/nohead/notrai/wid=fil=45
EISNER$DRA3:[DECUSERVE_USER.HEIN.A]X.X;1 (12345,1299,0)
EISNER$DRA3:[DECUSERVE_USER.HEIN.B]X.X;1 (38219,1299,0)
$ dele [.B]X.X;1
$ type [.A]x.x
%TYPE-W-OPENIN, error opening EISNER$DRA3:[DECUSERVE_USER.HEIN.A]X.X;1
as input
-RMS-E-FNF, file not found
btw.... RENAME was changed in the VMS 4.0 - 5.0 timeframe from first
enterring the second alias first and then removing the original to the
current remove first, add next, precisely for the reasons demonstructed
above. By removing first, a reasonable backlink becomes easy to
manage. Should the operation get interupted mid-stream, then there will
just be a lost file, which can be found back with no data loss.
Cheers,
Hein.
Bob Koehler
> OK, one more test:
>
> Create a 100k block file DISK:[CAKE]A.A
> SET FILE DISK:[CAKE]A.A/enter=DISK:[000000]B.B
> SHOW DEV DISK
> DELET/LOG [000000]B.B;
> SHOW DEV DISK
>
> DELETE says it has deleted 100k blocks. But Show DEV does not change the
> amount of free space on the disk.
>
The amount of free space is cached and not guarranteed to be up to
date unless you exersize a dismount, mount/rebuild cycle, at the
end of which the actual free space will be more than the listed
amount by the initial cache size.
Bob Koehler
>
> I noticed a new oddity: If you have B.B as an alias for A.A, then SET
> FILE/REMOVE A.A;!, you have only an alias left (B.B) which DFU reports
> as an alias for []A.A. But if you then DELETE B.B, delete really
> deletes it (and it cannot be recovered with ANAL/DISK) even though the
> filename in the file header doesn't match the name in the directory.
> (Checked on VAX/VMS 6.2)
Aliases are NOT links. If B.B is an alias for A.A and you delete
A.A, then the file is gone, including the A.A entry in the directory,
the A.A entry in the index, the A.A header, and the A.A data blocks.
B.B is then a broken alias. When you delete B.B, only the alias
is removed.
This is and always has been the way aliases worked from VMS 0.x
(where you had to use PIP to manage them), until links were added
to ODS-5: deleting the original is the only way to delete the file
and always deletes the file. Deleting an alias removes only the
alias entry and has no affect on the actual file.
Bob Koehler
> So you are correct. Your explanation actually covers both cases! I
> assume by DID you mean the back link file id.
The DID is the FID of the directory in which the file was created.
It can be found (along with the current name of the original file)
in the header, so the name in the header plus the DID uniquely
identify the original file.
An alias in a different directory will not have a directory FID
mathing the DID. An alias in the same directory will have a
different name in at least one field (version number included).
Although I'm fairly sure this is all well documented, playing around
with aliases, FIDs, and dump/header can be revealing for the
uninitiated.
Someday, when I get 8.2 or later on my hobbyist systems, I'll play
around with links. Never liked hard links on UNIX, not sure I'll
want to use them on VMS, they can play havoc with disk quotas.
But then I never did like, and rarely use, disk quotas.
AEF
Bob Koehler wrote:
> In article <1135121818....@g47g2000cwa.googlegroups.com>, "AEF" <spamsi...@yahoo.com> writes:
> >
> > I noticed a new oddity: If you have B.B as an alias for A.A, then SET
> > FILE/REMOVE A.A;!, you have only an alias left (B.B) which DFU reports
> > as an alias for []A.A. But if you then DELETE B.B, delete really
> > deletes it (and it cannot be recovered with ANAL/DISK) even though the
> > filename in the file header doesn't match the name in the directory.
> > (Checked on VAX/VMS 6.2)
>
> Aliases are NOT links. If B.B is an alias for A.A and you delete
> A.A, then the file is gone, including the A.A entry in the directory,
> the A.A entry in the index, the A.A header, and the A.A data blocks.
> B.B is then a broken alias. When you delete B.B, only the alias
> is removed.
But I didn't delete A.A. I SET FILE/REMOVE-ed it, leaving B.B as a bona
fide file except that it has the "wrong" filename in its header.
[...]
Here is an example to clarify (which was run on VAX/VMS V6.1):
$ DIREC/FILE/SIZE A.A
Directory DISK$DATA1:[FELDMAN.DCL.A]
A.A;1 (44856,3,0) 1
Total of 1 file, 1 block.
$ TYPE A.A
A.A
$ SET FILE A.A/ENTER=B.B
$ DIREC/FILE/SIZE
Directory DISK$DATA1:[FELDMAN.DCL.A]
A.A;1 (44856,3,0) 1
B.B;1 (44856,3,0) 1
Total of 2 files, 2 blocks.
$!!! OK, we now have A.A and its alias, B.B. I will remove A.A:
$ SET FILE/REMOVE A.A;
$ DIREC/FILE/SIZE
Directory DISK$DATA1:[FELDMAN.DCL.A]
B.B;1 (44856,3,0) 1
Total of 1 file, 1 block.
$ TYPE B.B
A.A
$!!! Now we have B.B as a bona fide file but which was originally an
alias for A.A. Now let's see what happens when we delete it:
$ DEL B.B;
%DELETE-I-FILDEL, DISK$DATA1:[FELDMAN.DCL.A]B.B;1 deleted (4 blocks)
$ DIREC/FILE/SIZE
%DIRECT-W-NOFILES, no files found
$ ANAL/DISK SYS$DISK:
Analyze/Disk_Structure for _NODEX$DKA200: started on 21-DEC-2005
23:02:36.34
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-NOSUCHFILE, no such file
$
The directory entry was removed and its file header has been freed up.
I hope this clears up what I was trying to say.
AEF
Hein RMS van den Heuvel
Fine example AEF.
I hope folks realize that one component, which was not nighlighted, and
which is critical in the behaviour, and that is the fact that A.A and
B.B live in the same directory. Thus that backlink would be the same no
matter which file is 'responsible' / the real McCoy. Creating entries
in other directories will change the game
There is no 'real file' versus aliasses.
All directory entries are created equal.
Whether one entry is deemed 'real' or 'just an alias' is by deduction,
not through an direct attribute of the entry.
If the directory entry lives in the directory pointed to by the file
header, or if the directory backpointer is invalid, then the entry is
'for real'. So it can even be a matter of timing. Wherever you look
first, that will be the real file. The fiel name in teh header is
immaterial to the file system, but us users may use it to label a given
directy entry as real vs alias.
Hein.
AEF
Hein RMS van den Heuvel wrote:
Thanks for pointing out that the file name in the header is immaterial
to aliases, contrary to one or more of my previous posts!
And thanks for clearing this matter up.
>
> Hein.
AEF
Dave Froble
Touchy! Chill out.
Re-reading, I see that I misunderstood your test, and therefore my
comments were baseless.
I haven't had time to do so yet, but I really do want to try some
variations when I get a chance.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. Fax: 724-529-0596
DFE Ultralights, Inc. E-Mail: da...@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA 15486
AEF
Dave Froble wrote:
> AEF wrote:
> > John Santos wrote:
> >
> >>Dave Froble wrote:
> >>
> >>>AEF wrote:
> >>>
> >>>
> >>>>John Santos wrote:
> >>>>
> >>>>
> >>>>>AEF wrote:
> >>>>>
> >>>>>
> >>>>>>JF Mezei wrote:
> >>>>>>
[...]
> >
> >
> >
> > ^^^^__________________________________________________________^^^^
> >
> >
> >>work exactly as Alan says, whether the files are in different
> >>directories or the same directory. (VAX V7.3 and Alpha V7.3-2 on ODS-2
> >>disks.)
> >
> > Well,
> > EEEEXXXXXXXXCCCCCCCCCCUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUSSSSSSSSSSSSEEEEEE
> > MMMMMMMMEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
> > for being right! Why is this such a big deal? Especially when it takes
> > less than 5 min. to check?
> >
> > Did I commit some great crime in cov? I am often accused of wrongdoing
> > I didn't do. So I'm not really that upset. And it DOES, not SEEMS to
> > do.
>
> Touchy! Chill out.
OK. Hey, it was half in jest. :=)
>
> Re-reading, I see that I misunderstood your test, and therefore my
> comments were baseless.
>
> I haven't had time to do so yet, but I really do want to try some
> variations when I get a chance.
Go for it! And read Hein's posts. He really has it nailed.
>
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. Fax: 724-529-0596
> DFE Ultralights, Inc. E-Mail: da...@tsoft-inc.com
> 170 Grimplin Road
> Vanderbilt, PA 15486
AEF
Bob Koehler
The following behaviour under ODS-5 on VMS 7.2-1 disagrees with your
assertion:
$ create a.a
a.a
Exit
$ set file a.a/enter=b.b
$ type b.b
a.a
$ del a.a;
$ type b.b
%TYPE-W-OPENIN, error opening USER1:[USER]b.b;1 as input
-RMS-E-FNF, file not found
$ dir/fu b.b
Directory USER1:[USER]
b.b;1 no such file
Total of 1 file, 0/0 blocks.
$ del b.b;
$ create a.a
a.a
Exit
$ set file a.a/enter=b.b
$ del b.b;
$ type a.a
a.a
So the original file (a.a) is treated differently from the alias
(b.b), even though they have the same DID.
Hein RMS van den Heuvel
directory.
Just to be sure I retested Bob's example with the names flipped around
in case it was being the first file that mattered.
My prior verifications had all been with multiple directories, I had
not tried teh single directory case exhaustively
Thanks for keeping me honest.
May or may not read up some more late.
Gotta run,
Hein.
JF Mezei
> $ create a.a
> a.a
> Exit
> $ set file a.a/enter=b.b
HELP SET FILE /ENTER on VAX VMS 7.2 warns of not creating aliases in
the same directory.
When you delete B.B, Delete looks up the backlink in indexF.SYS for that
file ID and finds that it is the directory that holds B.B so it thinks
that B.B is the real McCoy and deletes it.
And this has interesting corrolaries:
Create [X]A.A
The quick brown fox jumps over the lazy dog
SET FILE [X]A.A /ENTER=[X]B.B
At this point, B.B is "as real" as A.A since they are both in same directory.
RENAME [X]B.B [Y]B.B
Since B.B sits in the "official" directory for the file, RENAME would
then update INDEXF.SYS to have a backlink to the new [Y] directory. At
that time [X]A.A becomes an alias because it no longer sits in the
official directory for the file.
I hope I understood Hein's very good explanations correctly.
Bob Koehler
> Bob Koehler wrote:
>> $ create a.a
>> a.a
>> Exit
>> $ set file a.a/enter=b.b
>
> HELP SET FILE /ENTER on VAX VMS 7.2 warns of not creating aliases in
> the same directory.
>
> When you delete B.B, Delete looks up the backlink in indexF.SYS for that
> file ID and finds that it is the directory that holds B.B so it thinks
> that B.B is the real McCoy and deletes it.
>
Except my previous post shows that doesn't happen. And Hein just
tried it, too.
The warnings I see in HELP SET FILE/ENTER have to do with purging
(via PURGE or version limits) files accidentally. Since PURGE is
implemented by DELETE.EXE, I assume that's because purging the
original file can lead to broken aliases.
Anybody got the fiche (er, rather, the CD) handy and can tell us
for sure?
bri...@encompasserve.org
> The warnings I see in HELP SET FILE/ENTER have to do with purging
> (via PURGE or version limits) files accidentally. Since PURGE is
> implemented by DELETE.EXE, I assume that's because purging the
> original file can lead to broken aliases.
>
> Anybody got the fiche (er, rather, the CD) handy and can tell us
> for sure?
%DIRECT-W-NOFILES, no files found
$ create a.a
a.a
Exit
$
$ create b.b
b.b
Exit
$ dir /file
Directory EISNER$DRA3:[DECUSERVE_USER.BRIGGS.TEST]
A.A;1 (18665,97,0)
B.B;2 (23530,162,0)
B.B;1 (18665,97,0)
Total of 3 files.
$ purge /log
%PURGE-I-FILPURG, EISNER$DRA3:[DECUSERVE_USER.BRIGGS.TEST]B.B;1 deleted (3
block
s)
$ dir
Directory EISNER$DRA3:[DECUSERVE_USER.BRIGGS.TEST]
B.B;2 B.B;1
Total of 2 files.
Does that answer your question?
bri...@encompasserve.org
> (via PURGE or version limits) files accidentally. Since PURGE is
> implemented by DELETE.EXE, I assume that's because purging the
> original file can lead to broken aliases.
Here's a reproduction of the version limit issue
$ dir
%DIRECT-W-NOFILES, no files found
$ create a.a
a.a
Exit
$ set file /enter=b.b a.a
$ create b.b
b.b
Exit
$ set file /version=2 b.b
$ dir /file
Directory EISNER$DRA3:[DECUSERVE_USER.BRIGGS.TEST]
A.A;1 (16741,15179,0)
B.B;2 (30358,78,0)
B.B;1 (16741,15179,0)
Total of 3 files.
$ create b.b
b.b version 3
Exit
$ dir /file
Directory EISNER$DRA3:[DECUSERVE_USER.BRIGGS.TEST]
A.A;1 (16741,15179,0)
B.B;3 (30832,14401,0)
B.B;2 (30358,78,0)
Total of 3 files.
$ type a.a
%TYPE-W-OPENIN, error opening EISNER$DRA3:[DECUSERVE_USER.BRIGGS.TEST]A.A;1 as
i
nput
-RMS-E-FNF, file not found
David J Dachtera
I've seen a fair few systems where VMS$COMMON has an identity crisis -
thinks it's name (in the header) is SYSCOMMON, and in some cases
[SYS0.SYSCOMMON] is the "real" directory and [VMS$COMMON] is the alias
(good luck trying to do a VMS upgrade on *THAT*!).
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Coming soon:
Unofficial OpenVMS Marketing Home Page
AEF
David J Dachtera wrote:
> AEF wrote:
> >
> > Hein RMS van den Heuvel wrote:
> > > Fine example AEF.
> > > I hope folks realize that one component, which was not nighlighted, and
> > > which is critical in the behaviour, and that is the fact that A.A and
> > > B.B live in the same directory. Thus that backlink would be the same no
> > > matter which file is 'responsible' / the real McCoy. Creating entries
> > > in other directories will change the game
> > >
> > > There is no 'real file' versus aliasses.
> > > All directory entries are created equal.
> > > Whether one entry is deemed 'real' or 'just an alias' is by deduction,
> > > not through an direct attribute of the entry.
> > > If the directory entry lives in the directory pointed to by the file
> > > header, or if the directory backpointer is invalid, then the entry is
> > > 'for real'. So it can even be a matter of timing. Wherever you look
> > > first, that will be the real file. The fiel name in teh header is
> > > immaterial to the file system, but us users may use it to label a given
> > > directy entry as real vs alias.
> >
> > Thanks for pointing out that the file name in the header is immaterial
> > to aliases, contrary to one or more of my previous posts!
As demontrated by an experiment recently posted by Bob Koehler, the
file name does matter. OK.
> >
> > And thanks for clearing this matter up.
>
> I've seen a fair few systems where VMS$COMMON has an identity crisis -
> thinks it's name (in the header) is SYSCOMMON, and in some cases
> [SYS0.SYSCOMMON] is the "real" directory and [VMS$COMMON] is the alias
> (good luck trying to do a VMS upgrade on *THAT*!).
IIRC this results from restoring a system disk with an old enough
version of BACKUP. The first occurrence of a file becomes the primary
file even if it was originally the alias. In this case, VMSCOMMON.DIR
is originally primary. But during the restore, [SYS0]SYSCOMMON.DIR is
restored first, and because of the bug it is created as the primary
entry. I think this was fixed around VMS V6.2 as I recall seeing
something about it in those release notes. I think the cure is simple:
rename VMS$COMMON.DIR to SYSCOMMON and back to VMS$COMMON!. I'll check
the release notes at work tomorrow.
Bill Todd
> Bill Todd wrote:
...
>>ODS-2 both included the FID of the parent directory containing the
>>'primary' link and updated the name in the file header on RENAME
>>(presumably only when the file was RENAMEd through the 'primary' link),
>>and presumably changed the parent-directory FID if the file was RENAMEd
>>through the primary link to another directory. So the combination was
>>sufficient to ascertain whether a directory entry was an alias or not -
>>as long as no one screwed around manually with those header fields.
>>
>>This does not, however, explain the sequence where an alias was created,
>>the original link REMOVEd, and then the file successfully DELETEd via
>>the alias. Perhaps DELETE through an alias checks for the existence of
>>the primary link and if not present figures that it had better get rid
>>of the file as well as the alias (just in case it's the *last* alias).
>
>
> Perhaps you didn't read the other posts that explains this just fine.
Perhaps you have as little a clue about event ordering in the Usenet
propagation process (despite my having alluded to it in my own response)
as you have in so many other areas. And while I explicitly suggested
that someone with far more recent experience and/or actual knowledge of
the code step in (as Hein did), I don't feel particularly sheepish about
having figured out on my own to a fairly high degree of accuracy what it
was likely doing and for having provided some additional historical
background (which from your comments you yourself clearly lacked) in the
process.
- bill
Dave Froble
Well I hope we've reached the end of beating each other up over this
issue. I do have a question about the concept of alias directory entries.
I can understand the concept of having a file visable in multiple
locations. With the exception of distribution media and the use of
alias directory entries in the VMS directory structures, I'm pretty much
at a loss to figure out any other reasonable uses of the concept.
The example with two directory entries in the same directory was so far
outside what my simple mind would think of that I initially didn't
understand the description.
So, from a reasonable usage perspective, other than what I've mentioned,
why would anyone use multiple directory entries for the same file?
I guess that from a certain perspective alias directory entries is
another method of pointing to a file, something logicals are used for,
but I never would have thought of using them for such.
Bill Todd
> Well I hope we've reached the end of beating each other up over this
> issue.
No real beating involved, David. Aside from explaining what was going
on and adding/correcting some details about the VMS, RSX, and Unix
history behind it, all I did was answer an explicitly-framed question
(some might call it a 'whine', but it was certainly *phrased* as a
question) about why Alan's 'expertise' didn't seem to be getting the
degree of respect he thought it should.
People who don't like the answers they may get might be better-advised
not to ask questions that might result in such answers in the first
place, I'd say.
I do have a question about the concept of alias directory entries.
>
> I can understand the concept of having a file visable in multiple
> locations. With the exception of distribution media and the use of
> alias directory entries in the VMS directory structures, I'm pretty much
> at a loss to figure out any other reasonable uses of the concept.
Well, if you're asking for examples of where visibility from multiple
locations might be useful outside the two areas (VMS system and
'distribution media') that you mentioned, any situation where reference
from multiple (e.g., per-user-specific) locations to some central file
(or set of files, different versions of which serve different sets of
users) should qualify - especially when the per-user references are
hard-wired into some application that assumes the user has a private
copy in a specific location. Examples could be libraries, application
executables, or documents (both read-only and shared-update). Soft
('symbolic') links often can (in systems that support them) satisfy
these requirements without raising the interesting issues that hard
links do, but IIRC hard links were invented first (and indeed the
interesting issues therein later caused soft links to be added to Unix -
does VMS have anything like them?).
>
> The example with two directory entries in the same directory was so far
> outside what my simple mind would think of that I initially didn't
> understand the description.
As Hein noted, the old implementation of RENAME passed through an
intermediate state where both old and new names appeared in the same
directory if the RENAME was not cross-directory in nature.
While I agree that other uses may tend to be fairly rare, any case where
an application needed to change the name of one of its components but
wanted both old and new application versions to be able to find that
component under its known name in its traditional location (i.e., the
same directory) might use it.
...
> I guess that from a certain perspective alias directory entries is
> another method of pointing to a file, something logicals are used for,
> but I never would have thought of using them for such.
Perhaps you should turn the question around, and ask whether it would
really be worth prohibiting the practice (given that it's not something
that happens unless someone thinks there's some specific reason to make
it happen).
Many (most?) serious or even semi-serious file systems for the past 35
years (that I know of - it could easily be longer) have separated their
file system into a hierarchical directory portion supporting look-ups
and a 'file object' portion supporting actual content and metadata
related to that content. Unix and its derivatives (including most of
the proprietary file systems in commercial Unixes, several of which
eventually made their way to Linux) have their 'inodes' which are
largely functionally comparable to the contents of the 'index files' in
RSX and VMS systems. Windows' NTFS has its 'master file table' which is
even closer in nature to an RSX/VMS index file. Only the MS-DOS 'FAT'
file system comes to mind as a wide-spread example of the lack of such
separation (and FAT is hardly even a 'semi-serious' file system in my
book, though it's not all that unsuitable for most of the places in
which it's used).
When the look-up and target object implementations are so separated, one
would have to go out of one's way to prohibit the kind of aliasing we're
talking about here (though admittedly if you allow it then it's
reasonable to suggest that perhaps you should consider supporting it to
the degree that Unix or at least VMS does rather than just letting the
chips fall where they may as RSX did). And since this architecture
predates wide-spread availability (let alone use of) logical naming
facilities, letting it be put to use for aliasing when aliasing is
explicitly set up is not that hard to understand.
- bill
AEF
AEF wrote:
> David J Dachtera wrote:
[...]
> > I've seen a fair few systems where VMS$COMMON has an identity crisis -
> > thinks it's name (in the header) is SYSCOMMON, and in some cases
> > [SYS0.SYSCOMMON] is the "real" directory and [VMS$COMMON] is the alias
> > (good luck trying to do a VMS upgrade on *THAT*!).
>
> IIRC this results from restoring a system disk with an old enough
> version of BACKUP. The first occurrence of a file becomes the primary
> file even if it was originally the alias. In this case, VMSCOMMON.DIR
> is originally primary. But during the restore, [SYS0]SYSCOMMON.DIR is
> restored first, and because of the bug it is created as the primary
> entry. I think this was fixed around VMS V6.2 as I recall seeing
> something about it in those release notes. I think the cure is simple:
> rename VMS$COMMON.DIR to SYSCOMMON and back to VMS$COMMON!. I'll check
> the release notes at work tomorrow.
VAX/VMS V6.2 Release Notes Sec. 3.3.1.9 VMS$COMMON.DIR File: Restore
problems
To paraphrase, it says that BACKUP before VMS/VAX V5.5-2 and before VMS
Alpha V1.5 did not restore this file properly.
The only problem that results is that commands like SHOW ENTRY/FILES
and certain lexcial functions (F$GETQUI comes to mind) show
"[SYSCOMMON" instead of "[VMS$COMMON" as the leading portion of
file-specs. The system disk is unaffected otherwise.
[This is consistent with my memory that the first occurrence of a file
during a restore becomes the primary, even if it was originally the
alias.]
It gives a solution involving SET FILE/ENTER and SET FILE/REMOVE but I
think the easier solution renaming VMS$COMMON.DIR to SYSCOMMON and back
is easier and works just as well. Maybe there's a scenario in which you
need the SET FILE version, but I am not aware of it.
AEF
Alex Daniels
news:z6GdnYbeu59...@metrocastcablevision.com...
>Soft ('symbolic') links often can (in systems that support them) satisfy
>these requirements without raising the interesting issues that hard links
>do, but IIRC hard links were invented first (and indeed the interesting
>issues therein later caused soft links to be added to Unix - does VMS have
>anything like them?).
There are three 'options' in this area.
VMS supports the traditional aliases, which people have being discussing.
UNIX style symbolic links, (also with support for NFS), which are very new
to VMS, it's certainly available in field test for V8.2 / V8.2-1, but don't
think it has been properly released yet. ODS5 only.
Finally ODS5 supports hard links as well.
From the VMS docs...
"Both ODS-2 and ODS-5 support aliases, which are additional names for a file
or directory. Only ODS-5
supports hard links. One of the main differences with hard links enabled is
the way the DCL DELETE
command works. With hard links enabled, if you issue the DELETE command to
delete a file that has
one or more aliases associated with it, the command only deletes the alias
by which the file is being
accessed. The actual file continues to exist and is accessible by any
remaining alias. The file is deleted
only when the last remaining alias is deleted. Without hard links enabled,
the DELETE command
deletes both the alias by which the file is being accessed and the file
itself. Any other aliases remain but
the file is no longer accessible because it is no longer present. Thus, the
remaining aliases are unusable.
If enabling hard links has any drawbacks, they are minor and probably of
concern only in rare
circumstances. For example, if disk quotas are in effect, though owners of a
file can delete any links to a
file in a directory they can access, hard links in other users' directories
might cause a file to be retained,
and the file size continues to be charged against that owner's disk quota.
In general, be aware that enabling hard links does change the file system's
behavior and that applications
and management practices should respond accordingly (instead of being
alias-specific, for example)."
Alex
Bill Todd
...
Without hard links enabled,
> the DELETE command
> deletes both the alias by which the file is being accessed and the file
> itself. Any other aliases remain but
> the file is no longer accessible because it is no longer present. Thus, the
> remaining aliases are unusable.
Hmmm. Is this just an over-simplification of the actual behavior (see
earlier discussion about distinctions between the primary and additional
links in traditional ODS-2 environments), or do ODS-2 and ODS-5 differ
in their treatment of aliases (when hard links are not enabled in ODS-5)?
>
> If enabling hard links has any drawbacks, they are minor and probably of
> concern only in rare
> circumstances. For example, if disk quotas are in effect, though owners of a
> file can delete any links to a
> file in a directory they can access, hard links in other users' directories
> might cause a file to be retained,
> and the file size continues to be charged against that owner's disk quota.
That's one of the awkwardnesses I referred to earlier, and (as I noted)
there just *aren't* any *good* solutions, at least scalable ones (if you
don't have to worry about scaling you can just charge *every* user who
holds a link to the file - but this runs into scaling problems when the
file changes size or is deleted, and can also stick a user without
delete privilege with the file if s/he owns the last link standing
unless delete privilege is granted automatically in such a situation).
- bill
JF Mezei
> alias directory entries in the VMS directory structures, I'm pretty much
> at a loss to figure out any other reasonable uses of the concept.
Consider 2 applications with their own directory trees. They happen to
have many files in common. So you have a common directory where common
files reside. You have aliases to make this happen.
Yes, logicals are probably a better solution. But some applications are
hardcoded. And Unix appls ported to VMS have no concept of logical names.
Bob Koehler
>
> Finally ODS5 supports hard links as well.
>
With traditional aliases I could tell alias from original by DID
and the name in the header.
If I enable hard links on a volume, can I still also use traditional
aliases?
If so, is there a way to tell a traditional alias from a hard link?
AEF
Bob Koehler wrote:
> In article <43ac7c75$0$29572$da0f...@news.zen.co.uk>, "Alex Daniels" <alexNOSPAMHER...@themail.co.uk> writes:
> >
> > Finally ODS5 supports hard links as well.
> >
>
> With traditional aliases I could tell alias from original by DID
> and the name in the header.
>
> If I enable hard links on a volume, can I still also use traditional
> aliases?
No.
> If so, is there a way to tell a traditional alias from a hard link?
I don't know.
Look for hard links in the index of
http://h71000.www7.hp.com/doc/82FINAL/aa-pv5mj-tk/aa-pv5mj-tk.HTMl
(System manager's manual vol. 1: essentials
for more info.
AEF
AEF wrote:
> Bob Koehler wrote:
> > In article <43ac7c75$0$29572$da0f...@news.zen.co.uk>, "Alex Daniels" <alexNOSPAMHER...@themail.co.uk> writes:
> > >
> > > Finally ODS5 supports hard links as well.
> > >
> >
> > With traditional aliases I could tell alias from original by DID
> > and the name in the header.
> >
> > If I enable hard links on a volume, can I still also use traditional
> > aliases?
>
>
> No.
>
>
> > If so, is there a way to tell a traditional alias from a hard link?
>
>
> I don't know.
Sorry, I meant I don't know if you can tell if a disk is set for hard
links or for regular aliases without experimenting with the DELETE
command. It would be nice if this were indicated in SHOW DEVICE output.
Maybe it is, but I don't know. (I had read the question too quickly and
substituted something similar. Sorry about that!)
>
> Look for hard links in the index of
>
> http://h71000.www7.hp.com/doc/82FINAL/aa-pv5mj-tk/aa-pv5mj-tk.HTMl
>
> (System manager's manual vol. 1: essentials
>
>
> for more info.
AEF
Bob Koehler
> Sorry, I meant I don't know if you can tell if a disk is set for hard
> links or for regular aliases without experimenting with the DELETE
> command. It would be nice if this were indicated in SHOW DEVICE output.
> Maybe it is, but I don't know. (I had read the question too quickly and
> substituted something similar. Sorry about that!)
The system manager's manual says SHOW DEVICE/FULL does display that
info.