Re: Deleting alias files (blocks deleted)
- From: "AEF" <spamsink2001@xxxxxxxxx>
- Date: 22 Dec 2005 19:38:36 -0800
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.
>
> --
> 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
.
- Follow-Ups:
- References:
- Deleting alias files (blocks deleted)
- From: JF Mezei
- Re: Deleting alias files (blocks deleted)
- From: AEF
- Re: Deleting alias files (blocks deleted)
- From: Bob Koehler
- Re: Deleting alias files (blocks deleted)
- From: AEF
- Re: Deleting alias files (blocks deleted)
- From: Hein RMS van den Heuvel
- Re: Deleting alias files (blocks deleted)
- From: AEF
- Re: Deleting alias files (blocks deleted)
- From: David J Dachtera
- Deleting alias files (blocks deleted)
- Prev by Date: Re: Merry Christmas to All
- Next by Date: Re: Some people are willing to support their product
- Previous by thread: Re: Deleting alias files (blocks deleted)
- Next by thread: Re: Deleting alias files (blocks deleted)
- Index(es):
Relevant Pages
|