From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: [BUG] bug in org-publish and a (wrong) patch Date: Mon, 27 Jun 2011 00:12:11 -0400 Message-ID: <4871.1309147931@alphaville.dokosmarshall.org> References: <8052.1302153060@alphaville.dokosmarshall.org> <5365.1302281886@alphaville.usa.hp.com> <877h88mpkw.wl%dmaus@ictsoc.de> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([140.186.70.92]:49953) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qb3BV-00065B-RM for emacs-orgmode@gnu.org; Mon, 27 Jun 2011 00:12:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qb3BT-0002At-MO for emacs-orgmode@gnu.org; Mon, 27 Jun 2011 00:12:29 -0400 Received: from vms173005pub.verizon.net ([206.46.173.5]:52860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qb3BS-0002Ab-QT for emacs-orgmode@gnu.org; Mon, 27 Jun 2011 00:12:27 -0400 Received: from alphaville.dokosmarshall.org ([unknown] [173.76.32.106]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LNF00790L0CRF60@vms173005.mailsrvcs.net> for emacs-orgmode@gnu.org; Sun, 26 Jun 2011 23:12:13 -0500 (CDT) In-reply-to: Message from David Maus of "Sun, 26 Jun 2011 20:10:06 +0200." <877h88mpkw.wl%dmaus@ictsoc.de> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: David Maus Cc: bzg@altern.org, nicholas.dokos@hp.com, emacs-orgmode@gnu.org, Carsten Dominik David Maus wrote: > At Fri, 08 Apr 2011 12:58:06 -0400, > Nick Dokos wrote: > > > > Carsten Dominik wrote: > > > > > Hi Nick, > > > > > > I have not looked closely, but maybe you can use > > > > > > > > > (expand-file-name .... (file-name-directory filename)) > > > > > > to fix this patch? Not sure, I have not spent any time on it. > > > > > > > Almost but not quite: C-h v expand-file-name says > > > > ,---- > > | (expand-file-name NAME &optional DEFAULT-DIRECTORY) > > | > > | Convert filename NAME to absolute, and canonicalize it. > > | Second arg DEFAULT-DIRECTORY is directory to start with if NAME is relative > > | (does not start with slash or tilde); if DEFAULT-DIRECTORY is nil or missing, > > | the current buffer's value of `default-directory' is used. > > `---- > > > > so you end up tacking it onto a completely unrelated directory (and my > > experiments confirm this). > > > > But there is a :base-directory for the project that could be obtained > > from the project-plist and passed to expand-file-name. I think that > > would work but would require passing the project-plist down through a couple > > of layers to org-publish-cache-ctime-of-src. Alternatively, it (or just > > the base directory) could be bound dynamically in org-publish-file and > > used in the ctime function. > > > > What do you think would be preferable? > > Took some time, but attached patch fixes the problem w/o the need for > passing down :base-directory at all. Simply expand-filename only if > the symlink is relative; luckily the filename passed to this fun > already is absolute. > > @Bastien: Didn't push because I assume you already started the release > process for Org 7.6. > > From f6ed4d5707995f34a627886d0607dd7e6343144b Mon Sep 17 00:00:00 2001 > From: David Maus > Date: Sun, 26 Jun 2011 20:02:42 +0200 > Subject: [PATCH] Properly handle relative symlinks when publishing > > * org-publish.el (org-publish-cache-ctime-of-src): Properly handle > relative symlinks. > > At Thu, 07 Apr 2011 01:11:00 -0400, > Nick Dokos wrote: > > > > org-publish-cache-ctime-of-src tries (but does not always succeed) to > > deal with symlinks: file-symlink-p returns the target as a string, but > > if the target is relative to the symlink, that's not going to fly. > > e.g. if c is a symlink like this > > > > /a/b/c->../d/f > > > > then (file-symlink-p "/a/b/c") -> "../d/f" > > but if the current directory is any place other than /a/b, the target > > will not be found, the file attributes are going to be nil and > > the function will blow up. > --- > lisp/org-publish.el | 7 ++++--- > 1 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/lisp/org-publish.el b/lisp/org-publish.el > index 56cc80a..0d3d70a 100644 > --- a/lisp/org-publish.el > +++ b/lisp/org-publish.el > @@ -1157,9 +1157,10 @@ Returns value on success, else nil." > > (defun org-publish-cache-ctime-of-src (filename) > "Get the FILENAME ctime as an integer." > - (let ((src-attr (file-attributes (if (stringp (file-symlink-p filename)) > - (file-symlink-p filename) > - filename)))) > + (let* ((symlink-maybe (or (file-symlink-p filename) filename)) > + (src-attr (file-attributes (if (file-name-absolute-p symlink-maybe) > + symlink-maybe > + (expand-file-name symlink filename))))) > (+ > (lsh (car (nth 5 src-attr)) 16) > (cadr (nth 5 src-attr))))) > -- > 1.7.2.5 > I don't think it's correct as it stands: What is ``symlink'' on the last line? should it be be symlink-maybe perhaps? and expand-file-name expands wrt to the default directory passed as its third argument. Maybe the third argument can be (file-name-directory filename) as Carsten suggested, but surely it cannot be just ``filename''. Replacing the last line with (expand-file-name symlink-maybe (file-name-directory filename))... my (very simple) test case gets published correctly, so it's certainly better than what's there. Nick