emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-bug-tracker] bug#4674: closed (23.1; UNC paths and file-relative-


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#4674: closed (23.1; UNC paths and file-relative-directory)
Date: Sat, 04 Dec 2010 12:50:04 +0000

Your message dated Sat, 04 Dec 2010 14:55:28 +0200
with message-id <address@hidden>
and subject line Re: bug#4674: 23.1; UNC paths and file-relative-directory
has caused the GNU bug report #4673,
regarding 23.1; UNC paths and file-relative-directory
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
4673: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4673
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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"



--- End Message ---
--- Begin Message --- 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 <address@hidden>
> 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.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]