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
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

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?

- Raw text -