GNU bug report logs - #13930
Emacs doesn't cope well if it can't access/create .emacs.d

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 13930 in the body.
You can then email your comments to 13930 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Robert Prije <rprije <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs doesn't cope well if it can't access/create .emacs.d
Date: Tue, 12 Mar 2013 09:35:55 +0800

[Message part 1 (text/plain, inline)]

If emacs can't reach or create .emacs.d it gets into a sort of half-loaded
state.

Here's an example of how this causes problems for me:

I often have processes spawn emacs for me using sudo.

My home directory has 700 permissions and exists on a root-squashed NFS
share. Consequently root can't reach it.

As a result, whenever I run sudo emacs on a file, it throws the error:

"Creating directory: Permission denied, /home/rprije/.emacs.d/"

in my minibuffer. It fails to load my file and I have to do C-x C-f on the
file to open it manually. If it's a temporarily created file, it often
loses the file completely and I can't regain it.

I'd have expected running with -Q or -q would help but it sadly makes no
difference.

$ emacs --version
GNU Emacs 23.2.1

[Message part 2 (text/html, inline)]

Message #8 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Robert Prije <rprije <at> janestreet.com>
Cc: 13930 <at> debbugs.gnu.org
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Mon, 11 Mar 2013 23:43:09 -0400

> As a result, whenever I run sudo emacs on a file, it throws the error:
> "Creating directory: Permission denied, /home/rprije/.emacs.d/"

Can you run with --debug-init to hopefully get a backtrace showing in
which context this error is signaled?


        Stefan

Message #11 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Robert Prije <rprije <at> janestreet.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13930 <at> debbugs.gnu.org
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 12 Mar 2013 11:52:08 +0800

[Message part 1 (text/plain, inline)]

It does exactly the same thing with --debug-init (says "creating directory:
permission denied...") and supplies no further information.

I think --debug-init is for debugging an init file, right? It's not getting
as far as loading the init file so it won't be able to debug it.



On Tue, Mar 12, 2013 at 11:43 AM, Stefan Monnier
<monnier <at> iro.umontreal.ca>wrote:

> > As a result, whenever I run sudo emacs on a file, it throws the error:
> > "Creating directory: Permission denied, /home/rprije/.emacs.d/"
>
> Can you run with --debug-init to hopefully get a backtrace showing in
> which context this error is signaled?
>
>
>         Stefan
>

[Message part 2 (text/html, inline)]

Message #14 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Robert Prije <rprije <at> janestreet.com>
Cc: 13930 <at> debbugs.gnu.org
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 12 Mar 2013 01:11:39 -0400

> It does exactly the same thing with --debug-init (says "creating directory:
> permission denied...") and supplies no further information.
> I think --debug-init is for debugging an init file, right?  It's not getting
> as far as loading the init file so it won't be able to debug it.

Can you try it with a more recent Emacs?  E.g. 24.2 or 24.3?
I remember we fixed some bugs at some point that caused creation of
.emacs.d before there's a real need for it.


        Stefan

Message #17 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Robert Prije <rprije <at> janestreet.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 13930 <at> debbugs.gnu.org
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 12 Mar 2013 17:01:23 +0800

[Message part 1 (text/plain, inline)]

I built and reproduced the same problem with:

$ ./src/emacs --version
GNU Emacs 24.2.1



On Tue, Mar 12, 2013 at 1:11 PM, Stefan Monnier <monnier <at> iro.umontreal.ca>wrote:

> > It does exactly the same thing with --debug-init (says "creating
> directory:
> > permission denied...") and supplies no further information.
> > I think --debug-init is for debugging an init file, right?  It's not
> getting
> > as far as loading the init file so it won't be able to debug it.
>
> Can you try it with a more recent Emacs?  E.g. 24.2 or 24.3?
> I remember we fixed some bugs at some point that caused creation of
> .emacs.d before there's a real need for it.
>
>
>         Stefan
>

[Message part 2 (text/html, inline)]

Message #20 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Prije <rprije <at> janestreet.com>
Cc: monnier <at> iro.umontreal.ca, 13930 <at> debbugs.gnu.org
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 12 Mar 2013 18:10:23 +0200

> Date: Tue, 12 Mar 2013 11:52:08 +0800
> From: Robert Prije <rprije <at> janestreet.com>
> Cc: 13930 <at> debbugs.gnu.org
> 
> It does exactly the same thing with --debug-init (says "creating directory:
> permission denied...") and supplies no further information.

How about running it under GDB with a breakpoint on report_file_error
and on xsignal?  If you start GDB from the src directory of the Emacs
sources, the .gdbinit file there defines a command xbacktrace which
will produce a Lisp-level backtrace in addition to the C-level
backtrace produced by the "bt" command of GDB.

Message #23 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13930 <at> debbugs.gnu.org, Robert Prije <rprije <at> janestreet.com>
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 12 Mar 2013 12:29:23 -0400

Eli Zaretskii wrote:

>> It does exactly the same thing with --debug-init (says "creating directory:
>> permission denied...") and supplies no further information.
>
> How about running it under GDB with a breakpoint on report_file_error
> and on xsignal?  If you start GDB from the src directory of the Emacs
> sources, the .gdbinit file there defines a command xbacktrace which
> will produce a Lisp-level backtrace in addition to the C-level
> backtrace produced by the "bt" command of GDB.

Why do we need to jump through such hoops, when locate-user-emacs-file,
which Stefan has just added all over the place, says:

  Else return NEW-NAME in `user-emacs-directory', creating the
  directory if it does not exist.

Message #26 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Sven Joachim <svenjoac <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13930 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
	Robert Prije <rprije <at> janestreet.com>
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 12 Mar 2013 17:32:32 +0100

On 2013-03-12 17:10 +0100, Eli Zaretskii wrote:

>> Date: Tue, 12 Mar 2013 11:52:08 +0800
>> From: Robert Prije <rprije <at> janestreet.com>
>> Cc: 13930 <at> debbugs.gnu.org
>> 
>> It does exactly the same thing with --debug-init (says "creating directory:
>> permission denied...") and supplies no further information.

FWIW, this can be reproduced by creating ~/.emacs.d as a file rather
than a directory:

touch /tmp/.emacs.d
HOME=/tmp emacs --no-init-file

Than the error is "File exists: /tmp/.emacs.d/".

> How about running it under GDB with a breakpoint on report_file_error
> and on xsignal?  If you start GDB from the src directory of the Emacs
> sources, the .gdbinit file there defines a command xbacktrace which
> will produce a Lisp-level backtrace in addition to the C-level
> backtrace produced by the "bt" command of GDB.

Done that and found out that locate-user-emacs-file tries to create the
directory:

,----
| (gdb) xbacktrace
| "make-directory-internal" (0xffffca98)
| "make-directory" (0xffffcc1c)
| "locate-user-emacs-file" (0xffffcd98)
| 0x82d3208 PVEC_COMPILED
| "funcall" (0xffffcf10)
| "eval" (0xffffd080)
| "custom-reevaluate-setting" (0xffffd1fc)
| "mapc" (0xffffd308)
| "command-line" (0xffffd4bc)
| "normal-top-level" (0xffffd5d0)
| (gdb)
`----

Cheers,
       Sven

Message #29 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13930 <at> debbugs.gnu.org, rprije <at> janestreet.com
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 12 Mar 2013 18:48:22 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Robert Prije <rprije <at> janestreet.com>,  13930 <at> debbugs.gnu.org
> Date: Tue, 12 Mar 2013 12:29:23 -0400
> 
> Eli Zaretskii wrote:
> 
> >> It does exactly the same thing with --debug-init (says "creating directory:
> >> permission denied...") and supplies no further information.
> >
> > How about running it under GDB with a breakpoint on report_file_error
> > and on xsignal?  If you start GDB from the src directory of the Emacs
> > sources, the .gdbinit file there defines a command xbacktrace which
> > will produce a Lisp-level backtrace in addition to the C-level
> > backtrace produced by the "bt" command of GDB.
> 
> Why do we need to jump through such hoops, when locate-user-emacs-file,
> which Stefan has just added all over the place, says:
> 
>   Else return NEW-NAME in `user-emacs-directory', creating the
>   directory if it does not exist.

If you mean that remembering this was all you needed to deduce that
locate-user-emacs-file is the culprit, then good for you.  I never
remember such details (and this one I think I never knew about in the
first place).  A debugger will show the truth even if the problem is
in some other place, so it is (IMO) a more efficient way of finding
the root cause.

IOW, more often than not I find that "jumping through hoops" is the
shortest and most reliable way to solution.

Message #32 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Robert Prije <rprije <at> janestreet.com>
To: Sven Joachim <svenjoac <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	13930 <at> debbugs.gnu.org
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Mon, 13 May 2013 07:33:48 +0800

[Message part 1 (text/plain, inline)]

Hi, just checking what the status of this bug is?

Thanks.


On Wed, Mar 13, 2013 at 12:32 AM, Sven Joachim <svenjoac <at> gmx.de> wrote:

> On 2013-03-12 17:10 +0100, Eli Zaretskii wrote:
>
> >> Date: Tue, 12 Mar 2013 11:52:08 +0800
> >> From: Robert Prije <rprije <at> janestreet.com>
> >> Cc: 13930 <at> debbugs.gnu.org
> >>
> >> It does exactly the same thing with --debug-init (says "creating
> directory:
> >> permission denied...") and supplies no further information.
>
> FWIW, this can be reproduced by creating ~/.emacs.d as a file rather
> than a directory:
>
> touch /tmp/.emacs.d
> HOME=/tmp emacs --no-init-file
>
> Than the error is "File exists: /tmp/.emacs.d/".
>
> > How about running it under GDB with a breakpoint on report_file_error
> > and on xsignal?  If you start GDB from the src directory of the Emacs
> > sources, the .gdbinit file there defines a command xbacktrace which
> > will produce a Lisp-level backtrace in addition to the C-level
> > backtrace produced by the "bt" command of GDB.
>
> Done that and found out that locate-user-emacs-file tries to create the
> directory:
>
> ,----
> | (gdb) xbacktrace
> | "make-directory-internal" (0xffffca98)
> | "make-directory" (0xffffcc1c)
> | "locate-user-emacs-file" (0xffffcd98)
> | 0x82d3208 PVEC_COMPILED
> | "funcall" (0xffffcf10)
> | "eval" (0xffffd080)
> | "custom-reevaluate-setting" (0xffffd1fc)
> | "mapc" (0xffffd308)
> | "command-line" (0xffffd4bc)
> | "normal-top-level" (0xffffd5d0)
> | (gdb)
> `----
>
> Cheers,
>        Sven
>

[Message part 2 (text/html, inline)]

Message #35 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Robert Prije <rprije <at> janestreet.com>
Cc: 13930 <at> debbugs.gnu.org
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 14 May 2013 03:30:50 -0400

Does this patch work for you?

*** lisp/subr.el	2013-04-27 21:12:17 +0000
--- lisp/subr.el	2013-05-14 07:27:31 +0000
***************
*** 2643,2648 ****
--- 2643,2655 ----
  Note that this should end with a directory separator.
  See also `locate-user-emacs-file'.")
  
+ (custom-declare-variable-early 'user-emacs-directory-warning t
+   "Non-nil means warn if cannot access `user-emacs-directory'.
+ Set this to nil at your own risk..."
+   :type 'boolean
+   :group 'initialization
+   :version "24.4")
+ 
  (defun locate-user-emacs-file (new-name &optional old-name)
    "Return an absolute per-user Emacs-specific file name.
  If NEW-NAME exists in `user-emacs-directory', return it.
***************
*** 2658,2674 ****
                (file-readable-p at-home))
  	 at-home
         ;; Make sure `user-emacs-directory' exists,
!        ;; unless we're in batch mode or dumping Emacs
         (or noninteractive
  	   purify-flag
! 	   (file-accessible-directory-p
! 	    (directory-file-name user-emacs-directory))
  	   (let ((umask (default-file-modes)))
  	     (unwind-protect
  		 (progn
  		   (set-default-file-modes ?\700)
! 		   (make-directory user-emacs-directory))
  	       (set-default-file-modes umask))))
         bestname))))
  
  ;;;; Misc. useful functions.
--- 2665,2697 ----
                (file-readable-p at-home))
  	 at-home
         ;; Make sure `user-emacs-directory' exists,
!        ;; unless we're in batch mode or dumping Emacs.
         (or noninteractive
  	   purify-flag
! 	   (let (errtype)
! 	     (if (file-directory-p user-emacs-directory)
! 		 (or (file-accessible-directory-p user-emacs-directory)
! 		     (setq errtype "access"))
  	       (let ((umask (default-file-modes)))
  		 (unwind-protect
  		     (progn
  		       (set-default-file-modes ?\700)
! 		       (condition-case nil
! 			   (make-directory user-emacs-directory)
! 			 (error (setq errtype "create"))))
  		   (set-default-file-modes umask))))
+ 	     (when (and errtype
+ 			user-emacs-directory-warning
+ 			(not (get 'user-emacs-directory-warning 'this-session)))
+ 	       ;; Only warn once per Emacs session.
+ 	       (put 'user-emacs-directory-warning 'this-session t)
+ 	       (display-warning 'initialization
+ 				(format "\
+ Unable to %s `user-emacs-directory' (%s).
+ Any data that would normally be written there may be lost!
+ If you never want to see this message again,
+ customize the variable `user-emacs-directory-warning'."
+ 					errtype user-emacs-directory)))))
         bestname))))
  
  ;;;; Misc. useful functions.

Message #38 received at 13930 <at> debbugs.gnu.org (full text, mbox):

From: Robert Prije <rprije <at> janestreet.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 13930 <at> debbugs.gnu.org
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 14 May 2013 16:46:16 +0800

[Message part 1 (text/plain, inline)]

This is much better. I now get a separate window with the following error:

"Warning (initialization): Unable to create `user-emacs-directory'
(~/.emacs.d/).
Any data that would normally be written there may be lost!
If you never want to see this message again,
customize the variable `user-emacs-directory-warning'."

but the file I attempt to open still opens and I can edit it as usual. It
appears the patch works as intended. Which release is it likely to make it
to?

Thanks a bunch Glenn.



On Tue, May 14, 2013 at 3:30 PM, Glenn Morris <rgm <at> gnu.org> wrote:

>
> Does this patch work for you?
>
> *** lisp/subr.el        2013-04-27 21:12:17 +0000
> --- lisp/subr.el        2013-05-14 07:27:31 +0000
> ***************
> *** 2643,2648 ****
> --- 2643,2655 ----
>   Note that this should end with a directory separator.
>   See also `locate-user-emacs-file'.")
>
> + (custom-declare-variable-early 'user-emacs-directory-warning t
> +   "Non-nil means warn if cannot access `user-emacs-directory'.
> + Set this to nil at your own risk..."
> +   :type 'boolean
> +   :group 'initialization
> +   :version "24.4")
> +
>   (defun locate-user-emacs-file (new-name &optional old-name)
>     "Return an absolute per-user Emacs-specific file name.
>   If NEW-NAME exists in `user-emacs-directory', return it.
> ***************
> *** 2658,2674 ****
>                 (file-readable-p at-home))
>          at-home
>          ;; Make sure `user-emacs-directory' exists,
> !        ;; unless we're in batch mode or dumping Emacs
>          (or noninteractive
>            purify-flag
> !          (file-accessible-directory-p
> !           (directory-file-name user-emacs-directory))
>            (let ((umask (default-file-modes)))
>              (unwind-protect
>                  (progn
>                    (set-default-file-modes ?\700)
> !                  (make-directory user-emacs-directory))
>                (set-default-file-modes umask))))
>          bestname))))
>
>   ;;;; Misc. useful functions.
> --- 2665,2697 ----
>                 (file-readable-p at-home))
>          at-home
>          ;; Make sure `user-emacs-directory' exists,
> !        ;; unless we're in batch mode or dumping Emacs.
>          (or noninteractive
>            purify-flag
> !          (let (errtype)
> !            (if (file-directory-p user-emacs-directory)
> !                (or (file-accessible-directory-p user-emacs-directory)
> !                    (setq errtype "access"))
>                (let ((umask (default-file-modes)))
>                  (unwind-protect
>                      (progn
>                        (set-default-file-modes ?\700)
> !                      (condition-case nil
> !                          (make-directory user-emacs-directory)
> !                        (error (setq errtype "create"))))
>                    (set-default-file-modes umask))))
> +            (when (and errtype
> +                       user-emacs-directory-warning
> +                       (not (get 'user-emacs-directory-warning
> 'this-session)))
> +              ;; Only warn once per Emacs session.
> +              (put 'user-emacs-directory-warning 'this-session t)
> +              (display-warning 'initialization
> +                               (format "\
> + Unable to %s `user-emacs-directory' (%s).
> + Any data that would normally be written there may be lost!
> + If you never want to see this message again,
> + customize the variable `user-emacs-directory-warning'."
> +                                       errtype user-emacs-directory)))))
>          bestname))))
>
>   ;;;; Misc. useful functions.
>
>

[Message part 2 (text/html, inline)]

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

From: Glenn Morris <rgm <at> gnu.org>
To: 13930-done <at> debbugs.gnu.org
Subject: Re: bug#13930: Emacs doesn't cope well if it can't access/create
	.emacs.d
Date: Tue, 14 May 2013 12:01:51 -0400

Version: 24.4

Thanks for testing, applied to trunk. Barring unexpected, should be in 24.4.

Previous Next

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