Date: Wed, 23 Aug 2000 14:27:55 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: lauras AT softhome DOT net Message-Id: <2110-Wed23Aug2000142755+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b CC: djgpp-workers AT delorie DOT com In-reply-to: <39A2E301.29AD624C@softhome.net> (message from Laurynas Biveinis on Tue, 22 Aug 2000 22:30:57 +0200) Subject: Re: Symlinks are done! References: <39A2E301 DOT 29AD624C AT softhome DOT net> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Tue, 22 Aug 2000 22:30:57 +0200 > From: Laurynas Biveinis > > That's it. A big relief :-). The only things left > are few documentation tweaks and bugfixing. Hmm... I wonder if this is really all. What about the following functions: - remove, rename, rmdir, unlink: 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. - 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. > Last, but not the least, I'm very thankful to DJ, Eli, Martin, > Andris, Alain and all others who helped with ideas, objections, > FTP space, etc, etc... Most important, thank _you_ for doing all the hard work!