From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13807: updated version to avoid MS-Windows vs non-MS-Windows clashes Date: Mon, 04 Mar 2013 18:50:32 +0200 Message-ID: <83ip57t8h3.fsf@gnu.org> References: <512A98D5.7080000@cs.ucla.edu> <512D3508.1000906@cs.ucla.edu> <83txoxwq0p.fsf@gnu.org> <51326459.4030001@cs.ucla.edu> <83vc99tsbm.fsf@gnu.org> <51327F29.5000600@cs.ucla.edu> <83ppzgtp2c.fsf@gnu.org> <5133E313.5040701@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1362415983 4995 80.91.229.3 (4 Mar 2013 16:53:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Mar 2013 16:53:03 +0000 (UTC) Cc: 13807@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 04 17:53:25 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UCYdh-00056l-DA for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Mar 2013 17:53:25 +0100 Original-Received: from localhost ([::1]:39578 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCYdL-0007SV-VW for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Mar 2013 11:53:03 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:60201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCYdA-0007DE-1X for bug-gnu-emacs@gnu.org; Mon, 04 Mar 2013 11:52:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCYd5-0003AA-Aw for bug-gnu-emacs@gnu.org; Mon, 04 Mar 2013 11:52:51 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCYd5-0003A5-5w for bug-gnu-emacs@gnu.org; Mon, 04 Mar 2013 11:52:47 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UCYdK-0001OH-CF for bug-gnu-emacs@gnu.org; Mon, 04 Mar 2013 11:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Mar 2013 16:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13807 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 13807-submit@debbugs.gnu.org id=B13807.13624159365284 (code B ref 13807); Mon, 04 Mar 2013 16:53:02 +0000 Original-Received: (at 13807) by debbugs.gnu.org; 4 Mar 2013 16:52:16 +0000 Original-Received: from localhost ([127.0.0.1]:58930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYcW-0001N6-6Z for submit@debbugs.gnu.org; Mon, 04 Mar 2013 11:52:16 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:60060) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UCYcP-0001MI-RR for 13807@debbugs.gnu.org; Mon, 04 Mar 2013 11:52:10 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MJ500400A8GGH00@a-mtaout20.012.net.il> for 13807@debbugs.gnu.org; Mon, 04 Mar 2013 18:50:40 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJ50031TASE3CU0@a-mtaout20.012.net.il>; Mon, 04 Mar 2013 18:50:39 +0200 (IST) In-reply-to: <5133E313.5040701@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:72084 Archived-At: > Date: Sun, 03 Mar 2013 15:56:03 -0800 > From: Paul Eggert > CC: Stefan Monnier , 13807@debbugs.gnu.org > > > My testing indicates that 'readdir' does return the file's name, but > > every other system call I tried, including even 'lstat', fails with > > EPERM. (I don't know whether all NFS servers behave that way.) > > They don't. Traditional NFS servers are stateless, and do > not have a state where a file exists and its parent > directory is accessible but you cannot stat the file. I'd > even call that behavior a bug: file servers with that > behavior will cause problems with many GNU programs, > including Emacs. It would not be wise for Emacs to rely on > or encourage that behavior. Like it or not, it's out there, and others might bump into it. > > these issues are unrelated to the MS-Windows build of Emacs. > > I don't see why they're unrelated. If an MS-Windows Emacs > uses regular files for locks, these files get in the way of > GNU/Linux Emacs lock files, and that makes these issues pop up. > > > They existed since about forever, and we never cared. > > Why is it suddenly so important that this feature works > > It's important because the MS-Windows code was recently > changed to create lock files, the existence of which could > break GNU/Linux Emacs's locking. I meant what you wrote here: > There's another issue: a GNU/Linux Emacs might be using an > MS-Windows file system that does not support symbolic links. Such > an Emacs should use a regular-file lock, just as MS-Windows Emacs does, > which means that the code to create regular-file locks should be implementable > in POSIXish primitives. Also, locking should work even if the Emacs > instance that created a lock uses a symlink whereas the Emacs instance > trying to get the lock would use a regular file, or vice versa. These issues are unrelated to whether Emacs on Windows does or doesn't lock files. They existed before, as did the issue with FAT32 volumes being used from Posix hosts. And I think you exaggerate the probability of having Emacs running on Windows to access via NFS files shared with Posix systems. In my experience, this is quite rare (as is having people use Emacs on Windows in general). > + if (fd < 0) > + err = errno; > + else > + { > + ptrdiff_t lock_info_len = strlen (lock_info_str); > + err = 0; > + if (emacs_write (fd, lock_info_str, lock_info_len) != lock_info_len > + || fchmod (fd, S_IRUSR | S_IRGRP | S_IROTH) != 0) > + err = errno; This will need a no-op emulation of fchmod for Windows (since a file created here will be world-writable anyway). Other than that, I don't see any problems with your changes (but I didn't try to build with them, I only read them). Thanks.