From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master fails to build on FreeBSD when ACL support is on Date: Fri, 19 Jan 2018 15:53:33 -0500 Message-ID: References: <86o9lua0yx.fsf@phe.ftfl.ca> <834lnly8ht.fsf@gnu.org> <86vafy20sj.fsf@phe.ftfl.ca> <83o9lpuct5.fsf@gnu.org> <83lggtu1qn.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1516395161 28462 195.159.176.226 (19 Jan 2018 20:52:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 19 Jan 2018 20:52:41 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 19 21:52:36 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ecde8-0006JJ-3K for ged-emacs-devel@m.gmane.org; Fri, 19 Jan 2018 21:52:20 +0100 Original-Received: from localhost ([::1]:44396 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecdg7-0008Cn-VE for ged-emacs-devel@m.gmane.org; Fri, 19 Jan 2018 15:54:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecdfR-0008BD-Rz for emacs-devel@gnu.org; Fri, 19 Jan 2018 15:53:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecdfM-0003qs-Ut for emacs-devel@gnu.org; Fri, 19 Jan 2018 15:53:41 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:51206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecdfM-0003qW-PK; Fri, 19 Jan 2018 15:53:36 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w0JKrX2h010561; Fri, 19 Jan 2018 15:53:34 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 8F416607D3; Fri, 19 Jan 2018 15:53:33 -0500 (EST) In-Reply-To: <83lggtu1qn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 19 Jan 2018 20:45:04 +0200") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6204=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6204> : inlines <6323> : streams <1776521> : uri <2574765> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222097 Archived-At: >> > - (make-temp-file (file-name-nondirectory target-file))) >> > + ;; If target-file is relative and includes >> > + ;; leading directories, make-temp-file will >> > + ;; assume those leading directories exist >> > + ;; under temporary-file-directory, which might >> > + ;; not be true. So strip leading directories >> > + ;; from relative file names before calling >> > + ;; make-temp-file. >> > + (if (file-name-absolute-p target-file) >> > + (make-temp-file target-file) >> > + (make-temp-file >> > + (file-name-nondirectory target-file)))) >> >> Hmm.. the comment here doesn't explain the (file-name-absolute-p >> target-file) test, and the commit message > It doesn't? No, it doesn't explain why we create the temp file next to the target if target is absolute and we create it in /tmp if target is relative. >> Or maybe we should just never use /tmp and just go with >> (make-temp-file (expand-file-name target-file)) >> ? > Why is that better? Looking at the history of the code, the temp-file code started with (make-temp-file target-file) which seems to me to be the result of an oversight: the original coder probably didn't realize that such a call would either create the temp file in the same directory as target-file or under /tmp depending on whether target-file is relative or absolute. Furthermore, later the code does `rename-file` which is an operation which works much better when the old name and new new are both in the same partition. So I think the intention of the code was to always put the tempfile next to the target-file. Stefan