Message-ID: <39A3D5DF.F9F3B78F@softhome.net>
Date: Wed, 23 Aug 2000 15:47:11 +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 AT delorie DOT com
Subject: Re: Symlinks are done!
References: <39A2E301 DOT 29AD624C AT softhome DOT net> <2110-Wed23Aug2000142755+0300-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> > That's it. A big relief :-). The only things left
> > are few documentation tweaks and bugfixing.
> 
> Hmm... I wonder if this is really all.  

Oh... Cold shower.

> What about the following
> functions:
> 
>    - remove, rename, rmdir, unlink: 

Does the same apply to glob()?

> these are indeed documented not to
>      follow symlinks, but this refers to the last part of the file
>      name, I think, not to its directory part.  For example, this
>      call:
>            remove ("/foo/bar/baz/file");
> 
>      should resolve symlinks in "/foo/bar/baz", in case one or more of
>      them are symlinks.  Otherwise, `remove' will fail, because the
>      low-level DOS functions it calls don't know about symlinks.

OK, I'll write a new function (__solve_dir_symlinks?), wrapper for 
__solve_symlinks() which solves everything but the last path part.

> 
>    - tmpfile: it must resolve symlinks in the leading directories of
>      what tmpnam (called internally by tmpfile) returns.  That's
>      because tmpnam uses `access', which supports symlinks, but
>      tmpfile opens the file with _creatnew, which doesn't know about
>      symlinks.
> 
>      Similar considerations apply to mktemp and mkstemp.

Will do.

> Most important, thank _you_ for doing all the hard work!

Thanks :)

Laurynas