all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#13013: 24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory
@ 2012-11-27 17:24 Jambunathan K
  2012-11-27 18:01 ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Jambunathan K @ 2012-11-27 17:24 UTC (permalink / raw)
  To: 13013; +Cc: Ista Zahn


This report is a digest of following thread:
    http://www.mail-archive.com/emacs-orgmode@gnu.org/msg62455.html.

The problem is because of Emacs mangling file paths like this on Windows
XP.

    "c:/DOCUME~1/IZAHN/LOCALS~1/Temp/odt-8052VuJ/"
    "c:/Documents and Settings/IZAHN/Local Settings/Temp/odt-8052VuJ/content.xml"

The problem is better explained with ielm session below. 


Create a ielm buffer with 
    M-x ielm RET

and type out the following 4 lisp forms ONE-by-ONE.

    (setq org-e-odt-zip-dir (file-name-as-directory (make-temp-file "odt-" t)))

    (with-current-buffer (find-file-noselect (concat org-e-odt-zip-dir "content.xml") t) (buffer-file-name))

    (with-current-buffer (get-file-buffer (concat org-e-odt-zip-dir "content.xml")) (save-buffer 0))

    (get-file-buffer (concat org-e-odt-zip-dir "content.xml"))

Here is what Ista reports:

    *** Welcome to IELM ***  Type (describe-mode) for help.
    ELISP> (setq org-e-odt-zip-dir (file-name-as-directory (make-temp-file
    "odt-" t)))
    "c:/DOCUME~1/IZAHN/LOCALS~1/Temp/odt-8052VuJ/"
    ELISP> (with-current-buffer (find-file-noselect (concat
    org-e-odt-zip-dir "content.xml") t) (buffer-file-name))
    "c:/Documents and Settings/IZAHN/Local Settings/Temp/odt-8052VuJ/content.xml"
    ELISP> (with-current-buffer (get-file-buffer (concat org-e-odt-zip-dir
    "content.xml")) (save-buffer 0))
    *** Eval error ***  Wrong type argument: stringp, nil
    ELISP> (get-file-buffer (concat org-e-odt-zip-dir "content.xml"))
    nil
    ELISP>

I am surprised that `get-file-buffer' is returning nil.  Why is there a
mismatch between file names as reported by `file-name-as-directory' and
`buffer-file-name'.


The problem is seen with Ista's machine (CCed here) with the following
setup.
    ,----
    | GNU Emacs 24.2.1 (i386-mingw-nt5.1.2600) of 2012-08-28 on MARVIN
    | 
    | I have cygwin installed, but emacs is the windows version from
    | http://ftp.gnu.org/gnu/emacs/windows/
    | 
    | The OS is Windows XP professional with service pack 3.
    `----

Apparently the problem is not seen with either here or 
    ,----
    | Windows 7
    | GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601) of 2012-08-29 on MARVIN
    `----

here 
    ,----
    | GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601) of 2012-08-29 on MARVIN
    | Windows 7
    `----







^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#13013: 24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory
  2012-11-27 17:24 bug#13013: 24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory Jambunathan K
@ 2012-11-27 18:01 ` Eli Zaretskii
  2012-11-27 18:38   ` Stefan Monnier
  2012-11-27 18:59   ` Eli Zaretskii
  0 siblings, 2 replies; 6+ messages in thread
From: Eli Zaretskii @ 2012-11-27 18:01 UTC (permalink / raw)
  To: Jambunathan K; +Cc: istazahn, 13013

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Tue, 27 Nov 2012 22:54:57 +0530
> Cc: Ista Zahn <istazahn@gmail.com>
> 
> 
> This report is a digest of following thread:
>     http://www.mail-archive.com/emacs-orgmode@gnu.org/msg62455.html.

I will read it soon, for now replying only based on what you posted.

> The problem is because of Emacs mangling file paths like this on Windows
> XP.
> 
>     "c:/DOCUME~1/IZAHN/LOCALS~1/Temp/odt-8052VuJ/"
>     "c:/Documents and Settings/IZAHN/Local Settings/Temp/odt-8052VuJ/content.xml"

Emacs doesn't mangle file names.  Emacs uses the value of TEMP
environment variable, which Windows sets to a 8+3 alias of the long
name (evidently trying to avoid bugs in programs that don't handle
whitespace in file names).  Emacs then converts the 8+3 alias to the
full long name when it stores the file name in the buffer object of
the buffer that visits the file.

> Create a ielm buffer with 
>     M-x ielm RET
> 
> and type out the following 4 lisp forms ONE-by-ONE.
> 
>     (setq org-e-odt-zip-dir (file-name-as-directory (make-temp-file "odt-" t)))
> 
>     (with-current-buffer (find-file-noselect (concat org-e-odt-zip-dir "content.xml") t) (buffer-file-name))
> 
>     (with-current-buffer (get-file-buffer (concat org-e-odt-zip-dir "content.xml")) (save-buffer 0))
> 
>     (get-file-buffer (concat org-e-odt-zip-dir "content.xml"))

The solution is to call file-truename on

  (concat org-e-odt-zip-dir "content.xml")

Think of the 8+3 name as a symlink to the long file name.

> I am surprised that `get-file-buffer' is returning nil.

It returns nil because it compares file names with string-equal.

> Why is there a mismatch between file names as reported by
> `file-name-as-directory' and `buffer-file-name'.

See above.  Won't the same happen with symlinks?





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#13013: 24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory
  2012-11-27 18:01 ` Eli Zaretskii
@ 2012-11-27 18:38   ` Stefan Monnier
  2012-11-27 18:59   ` Eli Zaretskii
  1 sibling, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2012-11-27 18:38 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: istazahn, Jambunathan K, 13013

>> I am surprised that `get-file-buffer' is returning nil.
> It returns nil because it compares file names with string-equal.

I think this brings us back to a recent suggestion to get rid of
get-file-buffer and redefine it as an alias of find-buffer-visiting
(which should work fine in this case).


        Stefan





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#13013: 24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory
  2012-11-27 18:01 ` Eli Zaretskii
  2012-11-27 18:38   ` Stefan Monnier
@ 2012-11-27 18:59   ` Eli Zaretskii
  2012-11-27 19:23     ` Achim Gratz
  1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2012-11-27 18:59 UTC (permalink / raw)
  To: kjambunathan, istazahn; +Cc: 13013

> Date: Tue, 27 Nov 2012 20:01:19 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: istazahn@gmail.com, 13013@debbugs.gnu.org
> 
> > From: Jambunathan K <kjambunathan@gmail.com>
> > Date: Tue, 27 Nov 2012 22:54:57 +0530
> > Cc: Ista Zahn <istazahn@gmail.com>
> > 
> > 
> > This report is a digest of following thread:
> >     http://www.mail-archive.com/emacs-orgmode@gnu.org/msg62455.html.
> 
> I will read it soon, for now replying only based on what you posted.

Read it, but didn't learn anything useful.

> The problem is seen with Ista's machine (CCed here) with the following
> setup.
>     ,----
>     | GNU Emacs 24.2.1 (i386-mingw-nt5.1.2600) of 2012-08-28 on MARVIN
>     | 
>     | I have cygwin installed, but emacs is the windows version from
>     | http://ftp.gnu.org/gnu/emacs/windows/
>     | 
>     | The OS is Windows XP professional with service pack 3.
>     `----
> 
> Apparently the problem is not seen with either here or 
>     ,----
>     | Windows 7
>     | GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601) of 2012-08-29 on MARVIN
>     `----
> 
> here 
>     ,----
>     | GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601) of 2012-08-29 on MARVIN
>     | Windows 7
>     `----

Because Windows 7 doesn't put a 8+3 alias into TEMP, but instead uses
the full long file name.  Probably because XP still supports DOS
programs (via NTVDM), while Windows 7 tossed that support.

IOW, it works on Windows 7 "by sheer luck".





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#13013: 24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory
  2012-11-27 18:59   ` Eli Zaretskii
@ 2012-11-27 19:23     ` Achim Gratz
  2012-11-27 19:52       ` Eli Zaretskii
  0 siblings, 1 reply; 6+ messages in thread
From: Achim Gratz @ 2012-11-27 19:23 UTC (permalink / raw)
  To: 13013

Eli Zaretskii writes:
> Because Windows 7 doesn't put a 8+3 alias into TEMP, but instead uses
> the full long file name.  Probably because XP still supports DOS
> programs (via NTVDM), while Windows 7 tossed that support.

Win7 may not support DOS programs, but it still supports 8+3 filenames,
this is one of the easier ways to escape quoting hell on that platform.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#13013: 24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory
  2012-11-27 19:23     ` Achim Gratz
@ 2012-11-27 19:52       ` Eli Zaretskii
  0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2012-11-27 19:52 UTC (permalink / raw)
  To: Achim Gratz; +Cc: 13013

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Tue, 27 Nov 2012 20:23:08 +0100
> 
> Eli Zaretskii writes:
> > Because Windows 7 doesn't put a 8+3 alias into TEMP, but instead uses
> > the full long file name.  Probably because XP still supports DOS
> > programs (via NTVDM), while Windows 7 tossed that support.
> 
> Win7 may not support DOS programs, but it still supports 8+3 filenames,

Of course it does.  I never said it didn't.  I attempted to explain
why XP sets TEMP to something like C:\DOCUME~1\USERNAME\LOCALS~1\Temp,
whereas Windows 7 sets it to C:\Users\USERNAME\APPDATA\Local\Temp.





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-11-27 19:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-27 17:24 bug#13013: 24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory Jambunathan K
2012-11-27 18:01 ` Eli Zaretskii
2012-11-27 18:38   ` Stefan Monnier
2012-11-27 18:59   ` Eli Zaretskii
2012-11-27 19:23     ` Achim Gratz
2012-11-27 19:52       ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.