From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Maus Subject: Re: [BUG] bug in org-publish and a (wrong) patch Date: Mon, 27 Jun 2011 06:24:19 +0200 Message-ID: <874o3bx5os.wl%dmaus@ictsoc.de> References: <8052.1302153060@alphaville.dokosmarshall.org> <5365.1302281886@alphaville.usa.hp.com> <877h88mpkw.wl%dmaus@ictsoc.de> <4871.1309147931@alphaville.dokosmarshall.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Mon_Jun_27_06:24:19_2011-1"; micalg=pgp-sha256; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:37492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qb3a3-00043w-4U for emacs-orgmode@gnu.org; Mon, 27 Jun 2011 00:37:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qb3a0-00066g-U9 for emacs-orgmode@gnu.org; Mon, 27 Jun 2011 00:37:50 -0400 Received: from app1a.xlhost.de ([213.202.242.161]:39805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qb3N4-0003tl-5Z for emacs-orgmode@gnu.org; Mon, 27 Jun 2011 00:24:26 -0400 In-Reply-To: <4871.1309147931@alphaville.dokosmarshall.org> 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: nicholas.dokos@hp.com Cc: David Maus , emacs-orgmode@gnu.org, bzg@altern.org, Carsten Dominik --pgp-sign-Multipart_Mon_Jun_27_06:24:19_2011-1 Content-Type: multipart/mixed; boundary="Multipart_Mon_Jun_27_06:24:19_2011-1" --Multipart_Mon_Jun_27_06:24:19_2011-1 Content-Type: text/plain; charset=US-ASCII At Mon, 27 Jun 2011 00:12:11 -0400, Nick Dokos wrote: > > 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. Damn, you are right. This patch was composed way to sloppy. Here's a corrected one. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber.... dmjena@jabber.org Email..... dmaus@ictsoc.de --Multipart_Mon_Jun_27_06:24:19_2011-1 Content-Type: text/plain; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="0001-Properly-handle-relative-symlinks-when-publishing.patch" Content-Transfer-Encoding: base64 RnJvbSA2YWQ5ZjMzY2NiMmQ4NzAyZGQxZDQzNzVkZDgyOTk4ZjcyMDc4ZTYwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEYXZpZCBNYXVzIDxkbWF1c0BpY3Rzb2MuZGU+CkRhdGU6IFN1 biwgMjYgSnVuIDIwMTEgMjA6MDI6NDIgKzAyMDAKU3ViamVjdDogW1BBVENIXSBQcm9wZXJseSBo YW5kbGUgcmVsYXRpdmUgc3ltbGlua3Mgd2hlbiBwdWJsaXNoaW5nCgoqIG9yZy1wdWJsaXNoLmVs IChvcmctcHVibGlzaC1jYWNoZS1jdGltZS1vZi1zcmMpOiBQcm9wZXJseSBoYW5kbGUKcmVsYXRp dmUgc3ltbGlua3MuCgpBdCBUaHUsIDA3IEFwciAyMDExIDAxOjExOjAwIC0wNDAwLApOaWNrIERv a29zIHdyb3RlOgo+Cj4gb3JnLXB1Ymxpc2gtY2FjaGUtY3RpbWUtb2Ytc3JjIHRyaWVzIChidXQg ZG9lcyBub3QgYWx3YXlzIHN1Y2NlZWQpIHRvCj4gZGVhbCB3aXRoIHN5bWxpbmtzOiBmaWxlLXN5 bWxpbmstcCByZXR1cm5zIHRoZSB0YXJnZXQgYXMgYSBzdHJpbmcsIGJ1dAo+IGlmIHRoZSB0YXJn ZXQgaXMgcmVsYXRpdmUgdG8gdGhlIHN5bWxpbmssIHRoYXQncyBub3QgZ29pbmcgdG8gZmx5Lgo+ IGUuZy4gaWYgYyBpcyBhIHN5bWxpbmsgbGlrZSB0aGlzCj4KPiAgICAgL2EvYi9jLT4uLi9kL2YK Pgo+IHRoZW4gKGZpbGUtc3ltbGluay1wICIvYS9iL2MiKSAtPiAiLi4vZC9mIgo+IGJ1dCBpZiB0 aGUgY3VycmVudCBkaXJlY3RvcnkgaXMgYW55IHBsYWNlIG90aGVyIHRoYW4gL2EvYiwgdGhlIHRh cmdldAo+IHdpbGwgbm90IGJlIGZvdW5kLCB0aGUgZmlsZSBhdHRyaWJ1dGVzIGFyZSBnb2luZyB0 byBiZSBuaWwgYW5kCj4gdGhlIGZ1bmN0aW9uIHdpbGwgYmxvdyB1cC4KLS0tCiBsaXNwL29yZy1w dWJsaXNoLmVsIHwgICAgOSArKysrKystLS0KIDEgZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRpb25z KCspLCAzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3Avb3JnLXB1Ymxpc2guZWwgYi9s aXNwL29yZy1wdWJsaXNoLmVsCmluZGV4IDU2Y2M4MGEuLjU2NDY0MzAgMTAwNjQ0Ci0tLSBhL2xp c3Avb3JnLXB1Ymxpc2guZWwKKysrIGIvbGlzcC9vcmctcHVibGlzaC5lbApAQCAtMTE1Nyw5ICsx MTU3LDEyIEBAIFJldHVybnMgdmFsdWUgb24gc3VjY2VzcywgZWxzZSBuaWwuIgogCiAoZGVmdW4g b3JnLXB1Ymxpc2gtY2FjaGUtY3RpbWUtb2Ytc3JjIChmaWxlbmFtZSkKICAgIkdldCB0aGUgRklM RU5BTUUgY3RpbWUgYXMgYW4gaW50ZWdlci4iCi0gIChsZXQgKChzcmMtYXR0ciAoZmlsZS1hdHRy aWJ1dGVzIChpZiAoc3RyaW5ncCAoZmlsZS1zeW1saW5rLXAgZmlsZW5hbWUpKQotCQkJCSAgICAg ICAoZmlsZS1zeW1saW5rLXAgZmlsZW5hbWUpCi0JCQkJICAgICBmaWxlbmFtZSkpKSkKKyAgKGxl dCogKChzeW1saW5rLW1heWJlIChvciAoZmlsZS1zeW1saW5rLXAgZmlsZW5hbWUpIGZpbGVuYW1l KSkKKwkgKHNyYy1hdHRyIChmaWxlLWF0dHJpYnV0ZXMgKGlmIChmaWxlLW5hbWUtYWJzb2x1dGUt cCBzeW1saW5rLW1heWJlKQorCQkJCQlzeW1saW5rLW1heWJlCisJCQkJICAgICAgKGV4cGFuZC1m aWxlLW5hbWUgCisJCQkJICAgICAgIHN5bWxpbmstbWF5YmUKKwkJCQkgICAgICAgKGZpbGUtbmFt ZS1kaXJlY3RvcnkgZmlsZW5hbWUpKSkpKSkKICAgICAoKwogICAgICAobHNoIChjYXIgKG50aCA1 IHNyYy1hdHRyKSkgMTYpCiAgICAgIChjYWRyIChudGggNSBzcmMtYXR0cikpKSkpCi0tIAoxLjcu Mi41Cgo= --Multipart_Mon_Jun_27_06:24:19_2011-1-- --pgp-sign-Multipart_Mon_Jun_27_06:24:19_2011-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAk4IBfMACgkQma24O1pEeObEmQEAjt5pwrZK5vRDmOxeIoO9fbBg xwgiNY3uQIrnV+1raWEA/12HPLBmBHT0jguLbcrtpCX7Ghwou7snVqtZnC0Us6/L =xpKH -----END PGP SIGNATURE----- --pgp-sign-Multipart_Mon_Jun_27_06:24:19_2011-1--