GNU bug report logs - #4674
23.1; UNC paths and file-relative-directory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4674 in the body.
You can then email your comments to 4674 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; UNC paths and file-relative-directory
Date: Thu, 8 Oct 2009 14:54:38 +0100

The function `file-relative-directory' has logic to detect when the
two given paths are part of two separate directory trees, and to
return the absolute file name in such cases. That logic does not catch
the case when the two given paths are UNC paths on different servers.
For example, on my present network (where there are computers named
IOBATES and KERES), the form (file-relative-name "//iobates/e/temp"
"//keres/e/temp") returns "../../../iobates/e/temp", which is not a
valid relative path to "//iobates/e/temp" from "//keres/e/temp". This
is therefore a bug.

As a workaround, I have the following piece of advice in my
site-start. However I'm not sure that it is wise to mess with remote
file handling in this way.

(defadvice file-remote-p (around unc-host-and-share activate)
  "For UNC paths, return the first two components."
  (let ((file (ad-get-arg 0)))
    (save-match-data
      (if (and (eq system-type 'windows-nt)
               (string-match "\\`\\(//[^:/\\\\]+/[^:/\\\\]+\\)" file))
          (setq ad-return-value (match-string 1 file))
        ad-do-it))))

In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
 of 2009-07-30 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENG
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-: ( f i l e - r e l a t i v e - n a m e SPC " / /
i o b a t e s / e / t e m p " SPC " / / k e r e s /
e / t e m p " ) <return> M-x r e p o r t - e m a c
s - b u g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
"../../../iobates/e/temp"

Message #10 received at 4674 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: 4674 <at> debbugs.gnu.org
Subject: RE: 23.1; UNC paths and file-relative-directory
Date: Fri, 9 Oct 2009 17:28:11 +0100

Thinking about it, that advice can be changed so that it only returns
the server name, since "../SHARE2" is a valid relative path from
"//SERVER/SHARE1" to "//SERVER/SHARE2": change the regexp to something
more like "\\`\\(//[^:/\\]+\\)/[^:/\\]+".

I'm reconsidering my "I don't think that's wise" attitude towards this
workaround. It's probably not illogical to treat files on UNC paths as
remote files (even in the case when the server name resolves to the
local computer anyway), and the old piece of advice has worked okay
for me so far.

Apologies for sending this message to the wrong place yesterday (see bug #4763).

Message #13 received at 4674-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>, 4674-done <at> debbugs.gnu.org,
	4673-done <at> debbugs.gnu.org
Subject: Re: bug#4674: 23.1; UNC paths and file-relative-directory
Date: Sat, 04 Dec 2010 14:55:28 +0200

> Date: Thu, 8 Oct 2009 14:54:38 +0100
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 
> 
> The function `file-relative-directory' has logic to detect when the
> two given paths are part of two separate directory trees, and to
> return the absolute file name in such cases. That logic does not catch
> the case when the two given paths are UNC paths on different servers.
> For example, on my present network (where there are computers named
> IOBATES and KERES), the form (file-relative-name "//iobates/e/temp"
> "//keres/e/temp") returns "../../../iobates/e/temp", which is not a
> valid relative path to "//iobates/e/temp" from "//keres/e/temp". This
> is therefore a bug.

Thanks, I fixed this now on the Emacs-23 branch.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.