From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Remove S_IFLNK (was: windows build failure) Date: Sat, 26 Feb 2011 20:01:32 +0200 Message-ID: <83vd06oetf.fsf@gnu.org> References: <8739nhji0d.fsf@gmail.com> <4D62C1A3.2050407@cs.ucla.edu> <834o7xt985.fsf@gnu.org> <4D631AC3.3010600@cs.ucla.edu> <4D638488.50101@cs.ucla.edu> <4D642E50.7080006@cs.ucla.edu> <4D681EF8.3080308@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1298743611 10681 80.91.229.12 (26 Feb 2011 18:06:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Feb 2011 18:06:51 +0000 (UTC) Cc: cyd@stupidchicken.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 26 19:06:46 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PtOXS-0005Bq-7f for ged-emacs-devel@m.gmane.org; Sat, 26 Feb 2011 19:06:42 +0100 Original-Received: from localhost ([127.0.0.1]:55903 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtOSv-0002ej-V6 for ged-emacs-devel@m.gmane.org; Sat, 26 Feb 2011 13:02:01 -0500 Original-Received: from [140.186.70.92] (port=51366 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PtOSr-0002eW-5C for emacs-devel@gnu.org; Sat, 26 Feb 2011 13:01:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PtOSp-0002Kn-1f for emacs-devel@gnu.org; Sat, 26 Feb 2011 13:01:57 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:39876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PtOSo-0002KA-ON for emacs-devel@gnu.org; Sat, 26 Feb 2011 13:01:55 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LH800900KGHMK00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 26 Feb 2011 20:01:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.53.157]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LH8007E6KQERQO0@a-mtaout20.012.net.il>; Sat, 26 Feb 2011 20:01:30 +0200 (IST) In-reply-to: <4D681EF8.3080308@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:136559 Archived-At: > Date: Fri, 25 Feb 2011 13:28:24 -0800 > From: Paul Eggert > CC: emacs-devel@gnu.org > > > If all we need is define 2 always-fail functions for w32 and for > > MS-DOS, let's just do that on src/w32.c and src/msdos.c > > That sounds fine, and that can be combined with this approach, since > the w32 and DOS ports supply their own hand-built config.h files. > > However, we should also work around the known bugs with lstat etc. on > non-Windows platforms, which the Gnulib code handles. These have to > do with file names that have trailing slashes; some Unixish hosts > incorrectly treat "foo/" as a symbolic link, for example, even when > it's a directory or is nonexistent, if "foo" happens to be a symlink. I'd say if we didn't hear about these problems until now, they are not important enough to justify such heavyweight changes and added complexity with remapping functions, replacing them, etc. However, if Stefan and Chong are okay with this, so be it. > > Imagine: > > > > User: M-x make-symbolic-link RET foo RET bar RET > > Emacs: File bar already exists; make it a link anyway? > > User: yes RET > > Emacs: Making symbolic link: Function not implemented > > User: :-( why *&^%$#@! didn't you tell me that to begin with?? > > This scenario already occurs in the mainstream code. If I am running > Emacs on a GNU/Linux host, using files on a file server that does not > support symbolic links, I will already see behavior like that. It's > more consistent if Emacs's behavior is similar on Windows. I could quote Emerson about foolish consistency here (a Posix host would have hard time knowing in advance that the call will fail, whereas a Windows host doesn't have that problem), but again, if I'm the only one who cares about this, I give up. > Here's the revised patch (full version attached). Thanks. When you decide to merge it, please give me a day or two to add the stub functions for Windows and DOS, so that when you commit, these two ports will still build.