Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!comp.vuw.ac.nz!dsiramd!marcamd!tcnz2!greg
From: greg@tcnz2.tcnz.co.nz (super)
Newsgroups: comp.bugs.sys5
Subject: Re: NCR's symbolic links (was Re: Pack)
Summary: not completely useless
Keywords: NCR symbolic links
Message-ID: <143@tcnz2.tcnz.co.nz>
Date: 5 Aug 89 00:46:10 GMT
References: <138@tcnz2.tcnz.co.nz> <485@umigw.MIAMI.EDU> <737@toro.UUCP> <966@levels.sait.edu.au>
Reply-To: greg@tcnz2.UUCP (super)
Organization: Thomas Cook NZ Head Office, Auckland, NZ
Lines: 31

In article <966@levels.sait.edu.au> ccdn@levels.sait.edu.au (DAVID NEWALL) writes:
>In article <737@toro.UUCP>, nick@toro.UUCP (Nicholas Jacobs) writes:
>> Actually, NCR has implemented symbolic links for System V.
>
>NCR's implementation of symbolic links is almost unusable.  There is no
>way of telling if a link is a symbolic link or a hard link; and most
>programs break when they come across a symbolic link that points to a
>non-existant file (can't stat xxxx).

A friend of mine (wdr@csoft.co.nz) wrote a small number of utilities
to get around these problems, including one to cruise down the file
system and generate a script which could rebuild the current symbolic
links.

The major headache we had with them is that our dbms appeared to do
file locking on the filessystem:inode basis, but did not handle
symbolic links, so that two programs could lock the same data if they
were running in the DBMS on different file systems. We have not had 
the spate of DB corruptions we used to have since the last upgrade of
the software, but it is something to watch for.

greg
Disclaimer : no-one tells me what to write
Quote :   Have I aligned
            with a blown mind
              Wasted my time
                On a drawn blind -- Zappa

Greg Calkin                                   Thomas Cook N.Z. Limited,
...!uunet!vuwcomp!dsiramd!marcamd!tcnz2!greg  PO Box 24, Auckland CPO,
or greg@tcnz.co.nz                            New Zealand.    Phone (09)-793920