Date: Tue, 24 Aug 1999 09:43:57 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Laurynas Biveinis <lauras AT softhome DOT net>
cc: DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Re: Real symlinks for DJGPP?
In-Reply-To: <37BFECBA.57BFBD27@softhome.net>
Message-ID: <Pine.SUN.3.91.990824093543.12112P-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Sun, 22 Aug 1999, Laurynas Biveinis wrote:

> 2) open function checks for symlink file format, and if
> the file appears to be symlink, open real file instead.

I presume you realize how much this would harm performance of file I/O? 
The above means that every call to `_open' will have to read the file, in
order to know whether it is a link or a regular file, even if the 
application only wants to write to the file.  This also means that 
`_open' will have to call `stat', or some of its subroutines (because 
some special files, like character devices, e.g. CON or PRN, cannot be 
safely read).  A huge performance hit.

Is this really justified?  What are the advantages of supporting symlinks 
on a filesystem that doesn't know about symlinks?

> For supporting symlinks to directories chdir() should be 
> adjusted too.

And `opendir', and `findfirst', and `spawnv'.

> I'm waiting for advices.

I think we need to see the advantages of this before we can decide if 
this is worth the hassle.  Can you tell what will we gain?