Message-ID: <39AA8DF9.2639FD6@softhome.net>
Date: Mon, 28 Aug 2000 18:06:17 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Re: Patch: symlinks in mkstemp()
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000828175259 DOT 17210E-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> When I wrote my message with the list of functions I thought needed to
> support symlinks in leading directories, I scanned the contents of
> djlsr203.zip looking for such functions.  But it would be nice if someone
> else's eyes could revisit the list of file-oriented functions and verify
> that nothing is missing.

I think I will browse sources for one more time (this time with 
__solve_dir_symlinks() in mind), but if somebody comes across some 
obscure function sitting in the corner without symlinks, please tell me.

> The principle is that every function that is available on Unix should
> support symlinks.  

Right.

> Functions that are specific to DOS/Windows or to DJGPP
> do not need to support symlinks, 

Right. Besides, this is a good portability lesson: when one needs
to use opendir()/readdir(), and when findfirst() and so on.

> unless we have good reasons to add that
> (e.g., because many Unix compatibility functions call that non-Unix
> function).

It must be really a very good reason, though. In most cases all callers
should be updated instead. Otherwise it will lead to disasters: consider 
there is a symlink support in findfirst/findnext. And somebody writes nice 
program for walking directory tree. And there is somewhere a symlink to 
upper directory...

Laurynas