GNU bug report logs - #13298
24.3.50; Cannot write backup file; backing up in ~\.emacs.d\%backup%~

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 13298 in the body.
You can then email your comments to 13298 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: Dmitry Gutov <dgutov <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Cannot write backup file; backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 00:43:28 +0400

The latest trunk now spews an error each time it's closed.
A build from emacs-24 on the same system doesn't.


1. emacs -Q
2. M-x ido-mode OR M-x recentf-mode (either one's fine)
3. C-x C-c
4. See the message above and a new directory in ~\.emacs.d\ (if it
didn't exist already).

In GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601)
 of 2012-12-28 on SOL
Bzr revision: 111361 yamaoka <at> jpl.org-20121228122654-beasgii3cyci5ftg
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (3.4) --cflags -IJ:/Apps/System/gnuwin32/include'

Important settings:
  value of $EMACSDATA: C:/Users/gutov/vc/emacs-bzr/trunk/etc
  value of $EMACSDOC: C:/Users/gutov/vc/emacs-bzr/trunk/etc
  value of $EMACSLOADPATH: C:/Users/gutov/vc/emacs-bzr/trunk/site-lisp;C:/Users/gutov/vc/emacs-bzr/trunk/../site-lisp;C:/Users/gutov/vc/emacs-bzr/trunk/lisp;C:/Users/gutov/vc/emacs-bzr/trunk/leim
  value of $EMACSPATH: C:/Users/gutov/vc/emacs-bzr/trunk/bin
  value of $LANG: RUS
  locale-coding-system: cp1251
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  bug-reference-prog-mode: t
  recentf-mode: t
  shell-dirtrack-mode: t
  helm-match-plugin-mode: t
  elisp-slime-nav-mode: t
  paredit-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  global-diff-hl-mode: t
  diff-hl-mode: t
  diff-auto-refine-mode: t
  savehist-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  global-auto-revert-mode: t
  autopair-global-mode: t
  cua-mode: t
  winner-mode: t
  ido-ubiquitous-mode: t
  ido-everywhere: t
  show-paren-mode: t
  global-ethan-wspace-mode: t
  ethan-wspace-mode: t
  ethan-wspace-clean-many-nls-eof-mode: t
  ethan-wspace-clean-no-nl-eof-mode: t
  ethan-wspace-clean-eol-mode: t
  ethan-wspace-clean-tabs-mode: t
  eproject-mode: t
  eldoc-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t

Recent input:
C-; d e v e m v <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> i n i t . e l <return> 
<C-end> <S-up> <S-up> <S-up> <S-up> <S-up> <S-up> <S-up> 
<S-up> <S-up> <S-up> <S-up> <S-up> <S-up> M-; C-x C-s 
<lwindow> C-z C-x C-s <up> <S-up> <S-up> M-; C-x C-s 
<lwindow> <S-down> <S-down> M-; <up> <up> <up> <up> 
<S-down> <S-down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> <S-down> <S-down> <S-down> <S-down> 
<S-down> M-; C-x C-s <lwindow> C-z C-x C-s <help-echo> 
<down-mouse-1> <mouse-1> <home> <S-down> <S-down> <S-down> 
<S-down> <S-down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> <down> <S-up> <S-up> <S-up> <S-up> 
<S-up> <S-up> <S-up> <S-up> <S-up> <S-up> <S-up> <S-up> 
<S-up> <S-up> <S-up> <S-up> <S-up> <S-up> M-; C-x C-s 
<lwindow> <lwindow> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> <S-down> M-; C-x C-s <lwindow> <down-mouse-1> 
<mouse-1> C-x 3 C-x C-f C-d <return> C-x k <return> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <return> <down> <down> <down> <down> <lwindow> 
<lwindow> g <help-echo> <down-mouse-1> <mouse-1> g 
<help-echo> <help-echo> <down-mouse-1> <mouse-1> <help-echo> 
<help-echo> <help-echo> <help-echo> ^ <lwindow> <lwindow> 
<lwindow> <help-echo> <down-mouse-1> <mouse-1> C-x 
0 M-x C-g M-x r e p o r t <return>

Recent messages:
Saving file c:/Users/gutov/.emacs.d/init.el...
Wrote c:/Users/gutov/.emacs.d/init.el
Saving file c:/Users/gutov/.emacs.d/init.el...
Wrote c:/Users/gutov/.emacs.d/init.el
Saving file c:/Users/gutov/.emacs.d/init.el...
Wrote c:/Users/gutov/.emacs.d/init.el
byte-code: End of buffer
Saving file c:/Users/gutov/.emacs.d/init.el...
Wrote c:/Users/gutov/.emacs.d/init.el
Quit

Load-path shadows:
c:/Users/gutov/.emacs.d/elpa/magit-20121030.2025/.dir-locals hides c:/Users/gutov/.emacs.d/elpa/sunrise-commander-20121117.2055/.dir-locals
c:/Users/gutov/.emacs.d/elpa/zossima-20121117.108/zossima hides c:/Users/gutov/.emacs.d/site-lisp/zossima/zossima
c:/Users/gutov/.emacs.d/elpa/smartrep-20120905.2101/smartrep hides c:/Users/gutov/.emacs.d/site-lisp/smartrep.el/smartrep
c:/Users/gutov/.emacs.d/elpa/smartrep-20120905.2101/smartrep hides ~/.emacs.d/site-lisp/smartrep
c:/Users/gutov/.emacs.d/elpa/magit-20121030.2025/.dir-locals hides c:/Users/gutov/vc/emacs-bzr/trunk/lisp/gnus/.dir-locals

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils smerge-mode unsafep
bug-reference bug-reference-github helm-misc tramp-cache tramp-sh
recentf tree-widget wid-edit bow helm-files image-dired tramp
tramp-compat tramp-loaddefs shell pcomplete format-spec dired-x
dired-aux thingatpt helm-tags helm-locate helm-help helm-external
helm-bookmark helm-buffers helm-grep helm-regexp grep helm-elscreen
helm-utils compile helm-match-plugin helm helm-config elisp-slime-nav
etags paredit saveplace undo-tree diff diff-hl smartrep face-remap vc-hg
vc-git vc-dir ewoc vc vc-dispatcher diff-mode savehist yasnippet
autorevert autopair cua-base winner .emacs-loaddefs cyril-util
auto-complete-autoloads autopair-autoloads
bug-reference-github-autoloads clojure-mode-autoloads
coffee-mode-autoloads color-theme-solarized-autoloads
color-theme-autoloads column-marker-autoloads expand-region-autoloads
feature-mode-autoloads findr-autoloads flymake-coffee-autoloads
flymake-ruby-autoloads flymake-easy-autoloads helm-descbinds-autoloads
iedit-autoloads inflections-autoloads iy-go-to-char-autoloads
list-utils-autoloads markdown-mode-autoloads move-text-autoloads
occidental-theme-autoloads popup-autoloads popwin-autoloads
pos-tip-autoloads rainbow-mode-autoloads robe-autoloads
ruby-electric-autoloads ruby-tools-autoloads sass-mode-autoloads
haml-mode-autoloads finder-inf smartrep-autoloads win-switch
starter-kit-bindings-autoloads windmove starter-kit-lisp-autoloads
elisp-slime-nav-autoloads starter-kit-autoloads smex starter-kit-misc
warnings ffap url-parse auth-source eieio byte-opt bytecomp byte-compile
cconv gnus-util mm-util mail-prsvr password-cache url-vars
ido-ubiquitous ido paren starter-kit-defuns uniquify magit-autoloads
ido-ubiquitous-autoloads smex-autoloads find-file-in-project-autoloads
idle-highlight-mode-autoloads paredit-autoloads
sunrise-commander-autoloads switch-window-autoloads typing-autoloads
undo-tree-autoloads wgrep-autoloads win-switch-autoloads
yaml-mode-autoloads yasnippet-autoloads zossima-autoloads
inf-ruby-autoloads package devenv eproject-extras ibuf-macs ibuf-ext
ibuffer iswitchb ethan-wspace point-stack eproject derived easy-mmode
esh-var esh-io esh-cmd esh-opt esh-ext esh-proc esh-arg eldoc esh-groups
eshell esh-module esh-mode esh-util progmodes mmm mmm-auto mmm-vars
mmm-compat cl-macs gv cl cl-lib keys find-func quail help-mode easymenu
hippie hippie-exp comint ansi-color dired winring ring transpose-frame
iflipb misc prefs help-at-pt cus-start cus-load edmacro kmacro defuns
nadvice advice help-fns time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32notify w32
multi-tty emacs)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 09:11:44 +0200

> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 29 Dec 2012 00:43:28 +0400
> 
> The latest trunk now spews an error each time it's closed.
> A build from emacs-24 on the same system doesn't.
> 
> 
> 1. emacs -Q
> 2. M-x ido-mode OR M-x recentf-mode (either one's fine)
> 3. C-x C-c
> 4. See the message above and a new directory in ~\.emacs.d\ (if it
> didn't exist already).

Do you see a similar message when you edit a file and save it?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 15:25:54 +0400

On 29.12.2012 11:11, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Sat, 29 Dec 2012 00:43:28 +0400
>>
>> The latest trunk now spews an error each time it's closed.
>> A build from emacs-24 on the same system doesn't.
>>
>>
>> 1. emacs -Q
>> 2. M-x ido-mode OR M-x recentf-mode (either one's fine)
>> 3. C-x C-c
>> 4. See the message above and a new directory in ~\.emacs.d\ (if it
>> didn't exist already).
>
> Do you see a similar message when you edit a file and save it?

I don't (tried with non-vc-controlled files, to be sure).

But I see it when I quit gnus, by the way. Twice.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 14:06:45 +0200

> Date: Sat, 29 Dec 2012 15:25:54 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 13298 <at> debbugs.gnu.org
> 
> >> 1. emacs -Q
> >> 2. M-x ido-mode OR M-x recentf-mode (either one's fine)
> >> 3. C-x C-c
> >> 4. See the message above and a new directory in ~\.emacs.d\ (if it
> >> didn't exist already).
> >
> > Do you see a similar message when you edit a file and save it?
> 
> I don't (tried with non-vc-controlled files, to be sure).
> 
> But I see it when I quit gnus, by the way. Twice.

Can you step with a debugger (e.g., Edebug) through
backup-buffer-copy, and see why it errors out?  My crystal ball says
it happens because of set-file-extended-attributes, in which case
please tell what is the value of extended-attributes argument passed
to backup-buffer-copy.

Also, do you see any other error messages in *Messages* when this
happens?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 17:42:55 +0400

On 29.12.2012 16:06, Eli Zaretskii wrote:
>> Date: Sat, 29 Dec 2012 15:25:54 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> CC: 13298 <at> debbugs.gnu.org
>>
>>>> 1. emacs -Q
>>>> 2. M-x ido-mode OR M-x recentf-mode (either one's fine)
>>>> 3. C-x C-c
>>>> 4. See the message above and a new directory in ~\.emacs.d\ (if it
>>>> didn't exist already).
>>>
>>> Do you see a similar message when you edit a file and save it?
>>
>> I don't (tried with non-vc-controlled files, to be sure).
>>
>> But I see it when I quit gnus, by the way. Twice.
>
> Can you step with a debugger (e.g., Edebug) through
> backup-buffer-copy, and see why it errors out?  My crystal ball says
> it happens because of set-file-extended-attributes, in which case
> please tell what is the value of extended-attributes argument passed
> to backup-buffer-copy.

Indeed, it happens after a call to set-file-acl.

((acl . 
"O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)") 
(selinux-context nil nil nil nil))

> Also, do you see any other error messages in *Messages* when this
> happens?

Nope. Looks like this:

Saving file c:/Users/gutov/.newsrc...
Cannot write backup file; backing up in ~\.emacs.d\%backup%~
Wrote c:/Users/gutov/.newsrc
Saving c:/Users/gutov/.newsrc.eld...
Saving file c:/Users/gutov/.newsrc.eld...
Cannot write backup file; backing up in ~\.emacs.d\%backup%~
Wrote c:/Users/gutov/.newsrc.eld
Saving c:/Users/gutov/.newsrc.eld...done

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 15:51:50 +0200

> Date: Sat, 29 Dec 2012 17:42:55 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 13298 <at> debbugs.gnu.org
> 
> > Can you step with a debugger (e.g., Edebug) through
> > backup-buffer-copy, and see why it errors out?  My crystal ball says
> > it happens because of set-file-extended-attributes, in which case
> > please tell what is the value of extended-attributes argument passed
> > to backup-buffer-copy.
> 
> Indeed, it happens after a call to set-file-acl.
> 
> ((acl . 
> "O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)") 
> (selinux-context nil nil nil nil))

And if, before the call to set-file-acl inside
set-file-extended-attributes, you evaluate the expression

  (file-acl filename)

what does it return?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 17:55:58 +0400

On 29.12.2012 17:51, Eli Zaretskii wrote:
>> Date: Sat, 29 Dec 2012 17:42:55 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> CC: 13298 <at> debbugs.gnu.org
>>
>>> Can you step with a debugger (e.g., Edebug) through
>>> backup-buffer-copy, and see why it errors out?  My crystal ball says
>>> it happens because of set-file-extended-attributes, in which case
>>> please tell what is the value of extended-attributes argument passed
>>> to backup-buffer-copy.
>>
>> Indeed, it happens after a call to set-file-acl.
>>
>> ((acl .
>> "O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
>> (selinux-context nil nil nil nil))
>
> And if, before the call to set-file-acl inside
> set-file-extended-attributes, you evaluate the expression
>
>    (file-acl filename)
>
> what does it return?

"O:S-1-5-21-909999172-181315677-756075521-1000G:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)"

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 16:44:34 +0200

> Date: Sat, 29 Dec 2012 17:55:58 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 13298 <at> debbugs.gnu.org
> 
> On 29.12.2012 17:51, Eli Zaretskii wrote:
> >> Date: Sat, 29 Dec 2012 17:42:55 +0400
> >> From: Dmitry Gutov <dgutov <at> yandex.ru>
> >> CC: 13298 <at> debbugs.gnu.org
> >>
> >>> Can you step with a debugger (e.g., Edebug) through
> >>> backup-buffer-copy, and see why it errors out?  My crystal ball says
> >>> it happens because of set-file-extended-attributes, in which case
> >>> please tell what is the value of extended-attributes argument passed
> >>> to backup-buffer-copy.
> >>
> >> Indeed, it happens after a call to set-file-acl.
> >>
> >> ((acl .
> >> "O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
> >> (selinux-context nil nil nil nil))
> >
> > And if, before the call to set-file-acl inside
> > set-file-extended-attributes, you evaluate the expression
> >
> >    (file-acl filename)
> >
> > what does it return?
> 
> "O:S-1-5-21-909999172-181315677-756075521-1000G:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)"

I guess this happens because all of the following:

  . your user is a local Administrator

  . you took ownership of your ~/.emacs.d directory, instead of
    leaving it owned by the Administrators group

  . you didn't (or cannot) enable the "take ownership" privilege in
    your local security policy

Because of this, the files created inside ~/.emacs.d inherit the
owner of that directory, i.e. your user-id, while the original file
that is being backed up had the Administrators group as its owner
(that's what the "O:BA" part above means).  And because you don't have
the privileges of taking ownership, the call to set-file-acl fails.

I installed as trunk revision 111369 a set of changes that should fix
this for you.  Please test.  (I could only approximate the problem on
my machine, so I cannot be sure the changes indeed fix it.)

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 20:05:23 +0400

On 29.12.2012 18:44, Eli Zaretskii wrote:
>> Date: Sat, 29 Dec 2012 17:55:58 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> CC: 13298 <at> debbugs.gnu.org
>>
>> On 29.12.2012 17:51, Eli Zaretskii wrote:
>>>> Date: Sat, 29 Dec 2012 17:42:55 +0400
>>>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>>> CC: 13298 <at> debbugs.gnu.org
>>>>
>>>>> Can you step with a debugger (e.g., Edebug) through
>>>>> backup-buffer-copy, and see why it errors out?  My crystal ball says
>>>>> it happens because of set-file-extended-attributes, in which case
>>>>> please tell what is the value of extended-attributes argument passed
>>>>> to backup-buffer-copy.
>>>>
>>>> Indeed, it happens after a call to set-file-acl.
>>>>
>>>> ((acl .
>>>> "O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
>>>> (selinux-context nil nil nil nil))
>>>
>>> And if, before the call to set-file-acl inside
>>> set-file-extended-attributes, you evaluate the expression
>>>
>>>     (file-acl filename)
>>>
>>> what does it return?
>>
>> "O:S-1-5-21-909999172-181315677-756075521-1000G:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)"
>
> I guess this happens because all of the following:
>
>    . your user is a local Administrator
>
>    . you took ownership of your ~/.emacs.d directory, instead of
>      leaving it owned by the Administrators group

The above is true. But /Users/gutov is owned by SYSTEM, FWIW.

>    . you didn't (or cannot) enable the "take ownership" privilege in
>      your local security policy

This policy's security setting says "Administrators", and my user 
belongs to that group (I'm looking in Local Policies/User Rights 
Assignment, is that right?).

If I want to change the ownership, I open the Advanced Security Settings 
window, switch to the Owner tab, and the Edit button has the "security 
shield" button on it, which I can click, the edit window opens, I can 
make changes and save. All this without logging in as a different user, 
or even seeing the UAC prompt (in Windows Explorer).

Third-party applications might need a UAC prompt for that, I imagine.

> Because of this, the files created inside ~/.emacs.d inherit the
> owner of that directory, i.e. your user-id, while the original file
> that is being backed up had the Administrators group as its owner
> (that's what the "O:BA" part above means).  And because you don't have
> the privileges of taking ownership, the call to set-file-acl fails.
>
> I installed as trunk revision 111369 a set of changes that should fix
> this for you.  Please test.  (I could only approximate the problem on
> my machine, so I cannot be sure the changes indeed fix it.)

It's better, but now I see these messages:

Saving file c:/Users/gutov/.newsrc...
Error: (file-error "Setting ACL" "operation not permitted" 
"c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.newsrc~")
Wrote c:/Users/gutov/.newsrc
Saving c:/Users/gutov/.newsrc.eld...
Saving file c:/Users/gutov/.newsrc.eld...
Error: (file-error "Setting ACL" "operation not permitted" 
"c:/Users/gutov/.emacs.d/backups/!drive_c!Users!gutov!.newsrc.eld~")
Wrote c:/Users/gutov/.newsrc.eld
Saving c:/Users/gutov/.newsrc.eld...done

Like I described, I don't think my situation is exceptional, so seeing 
the error messages is misleading.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 18:59:48 +0200

> Date: Sat, 29 Dec 2012 20:05:23 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 13298 <at> debbugs.gnu.org
> 
> On 29.12.2012 18:44, Eli Zaretskii wrote:
> >> Date: Sat, 29 Dec 2012 17:55:58 +0400
> >> From: Dmitry Gutov <dgutov <at> yandex.ru>
> >> CC: 13298 <at> debbugs.gnu.org
> >>
> >> On 29.12.2012 17:51, Eli Zaretskii wrote:
> >>>> Date: Sat, 29 Dec 2012 17:42:55 +0400
> >>>> From: Dmitry Gutov <dgutov <at> yandex.ru>
> >>>> CC: 13298 <at> debbugs.gnu.org
> >>>>
> >>>>> Can you step with a debugger (e.g., Edebug) through
> >>>>> backup-buffer-copy, and see why it errors out?  My crystal ball says
> >>>>> it happens because of set-file-extended-attributes, in which case
> >>>>> please tell what is the value of extended-attributes argument passed
> >>>>> to backup-buffer-copy.
> >>>>
> >>>> Indeed, it happens after a call to set-file-acl.
> >>>>
> >>>> ((acl .
> >>>> "O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
> >>>> (selinux-context nil nil nil nil))
> >>>
> >>> And if, before the call to set-file-acl inside
> >>> set-file-extended-attributes, you evaluate the expression
> >>>
> >>>     (file-acl filename)
> >>>
> >>> what does it return?
> >>
> >> "O:S-1-5-21-909999172-181315677-756075521-1000G:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)"
> >
> > I guess this happens because all of the following:
> >
> >    . your user is a local Administrator
> >
> >    . you took ownership of your ~/.emacs.d directory, instead of
> >      leaving it owned by the Administrators group
> 
> The above is true. But /Users/gutov is owned by SYSTEM, FWIW.
> 
> >    . you didn't (or cannot) enable the "take ownership" privilege in
> >      your local security policy
> 
> This policy's security setting says "Administrators", and my user 
> belongs to that group (I'm looking in Local Policies/User Rights 
> Assignment, is that right?).

You could try explicitly allowing the privilege for your user, but I'm
not sure it would help.  That's the "cannot" part above: for users who
are members of the Administrators group, enabling that privilege does
nothing, AFAIK.  Windows doesn't let such users this privilege without
elevation.  You can only avoid the problem by running Emacs "as
Administrator" or from a shell that was run "as Administrator".

> > I installed as trunk revision 111369 a set of changes that should fix
> > this for you.  Please test.  (I could only approximate the problem on
> > my machine, so I cannot be sure the changes indeed fix it.)
> 
> It's better, but now I see these messages:
> 
> Saving file c:/Users/gutov/.newsrc...
> Error: (file-error "Setting ACL" "operation not permitted" 

This is what the changes intended to accomplish.  In this discussion:

  http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00568.html

I suggested to ignore these errors entirely, but others felt this was
too radical, since there could be real security issues involved here.
Stefan suggested using with-demoted-errors here:

  http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00645.html

which is what Emacs does after my changes.

> Like I described, I don't think my situation is exceptional, so seeing 
> the error messages is misleading.

Why misleading?  We asked Emacs to preserve the ACLs of the original
file, and it couldn't.  Shouldn't the user be informed about that?

If you think this is bad behavior, lobby on emacs-devel to allow some
kind of user options for ignoring these errors (which means you don't
care about security of access to your files).

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 21:18:54 +0400

On 29.12.2012 20:59, Eli Zaretskii wrote:
>> Date: Sat, 29 Dec 2012 20:05:23 +0400
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> CC: 13298 <at> debbugs.gnu.org
>>
>> On 29.12.2012 18:44, Eli Zaretskii wrote:
>>>> Date: Sat, 29 Dec 2012 17:55:58 +0400
>>>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>>> CC: 13298 <at> debbugs.gnu.org
>>>>
>>>> On 29.12.2012 17:51, Eli Zaretskii wrote:
>>>>>> Date: Sat, 29 Dec 2012 17:42:55 +0400
>>>>>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>>>>> CC: 13298 <at> debbugs.gnu.org
>>>>>>
>>>>>>> Can you step with a debugger (e.g., Edebug) through
>>>>>>> backup-buffer-copy, and see why it errors out?  My crystal ball says
>>>>>>> it happens because of set-file-extended-attributes, in which case
>>>>>>> please tell what is the value of extended-attributes argument passed
>>>>>>> to backup-buffer-copy.
>>>>>>
>>>>>> Indeed, it happens after a call to set-file-acl.
>>>>>>
>>>>>> ((acl .
>>>>>> "O:BAG:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)")
>>>>>> (selinux-context nil nil nil nil))
>>>>>
>>>>> And if, before the call to set-file-acl inside
>>>>> set-file-extended-attributes, you evaluate the expression
>>>>>
>>>>>      (file-acl filename)
>>>>>
>>>>> what does it return?
>>>>
>>>> "O:S-1-5-21-909999172-181315677-756075521-1000G:S-1-5-21-909999172-181315677-756075521-513D:(A;;FA;;;SY)(A;;FA;;;BA)(A;;FA;;;S-1-5-21-909999172-181315677-756075521-1000)"
>>>
>>> I guess this happens because all of the following:
>>>
>>>     . your user is a local Administrator
>>>
>>>     . you took ownership of your ~/.emacs.d directory, instead of
>>>       leaving it owned by the Administrators group
>>
>> The above is true. But /Users/gutov is owned by SYSTEM, FWIW.
>>
>>>     . you didn't (or cannot) enable the "take ownership" privilege in
>>>       your local security policy
>>
>> This policy's security setting says "Administrators", and my user
>> belongs to that group (I'm looking in Local Policies/User Rights
>> Assignment, is that right?).
>
> You could try explicitly allowing the privilege for your user, but I'm
> not sure it would help.  That's the "cannot" part above: for users who
> are members of the Administrators group, enabling that privilege does
> nothing, AFAIK.  Windows doesn't let such users this privilege without
> elevation.  You can only avoid the problem by running Emacs "as
> Administrator" or from a shell that was run "as Administrator".

Yeah, that's not going to happen.

Why doesn't Emacs try to show the elevation dialog, anyway?

>>> I installed as trunk revision 111369 a set of changes that should fix
>>> this for you.  Please test.  (I could only approximate the problem on
>>> my machine, so I cannot be sure the changes indeed fix it.)
>>
>> It's better, but now I see these messages:
>>
>> Saving file c:/Users/gutov/.newsrc...
>> Error: (file-error "Setting ACL" "operation not permitted"
>
> This is what the changes intended to accomplish.  In this discussion:
>
>    http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00568.html
>
> I suggested to ignore these errors entirely, but others felt this was
> too radical, since there could be real security issues involved here.

I've seen that discussion, but didn't feel I was qualified to comment.

> Stefan suggested using with-demoted-errors here:
>
>    http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00645.html
>
> which is what Emacs does after my changes.
>
>> Like I described, I don't think my situation is exceptional, so seeing
>> the error messages is misleading.
>
> Why misleading?  We asked Emacs to preserve the ACLs of the original
> file, and it couldn't.  Shouldn't the user be informed about that?

It leads me to believe that there's either something wrong with my 
system, or Emacs configuration, whereas I don't know why I should care 
that the backup function doesn't correctly set the file ownership.

I guess I might care about it in some other case.

> If you think this is bad behavior, lobby on emacs-devel to allow some
> kind of user options for ignoring these errors (which means you don't
> care about security of access to your files).

I don't think that a user option is the way to go if it's going to be 
off by default.

Maybe don't expect the user to customize its value, and bind it to t in 
certain functions, like backup-buffer-copy, instead?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 19:28:31 +0200

> Date: Sat, 29 Dec 2012 21:18:54 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 13298 <at> debbugs.gnu.org
> 
> Why doesn't Emacs try to show the elevation dialog, anyway?

The elevation dialog comes from Windows, when it does.  Applications
don't show it, they just can trigger it by performing operations that
require elevation.  But UAC behaves strangely when Administrators are
involved.

> >> Like I described, I don't think my situation is exceptional, so seeing
> >> the error messages is misleading.
> >
> > Why misleading?  We asked Emacs to preserve the ACLs of the original
> > file, and it couldn't.  Shouldn't the user be informed about that?
> 
> It leads me to believe that there's either something wrong with my 
> system, or Emacs configuration, whereas I don't know why I should care 
> that the backup function doesn't correctly set the file ownership.

You could try taking care of this issue by manually taking ownership
of the C:\Users\Gutov directory and all of its files and
subdirectories.  Setting the owner of C:\Users\Gutov to either your
user or the Administrators group will probably resolve the problem.
Doing the former, i.e. setting your user as the owner, sounds like TRT
to me anyway, it doesn't make sense to me to have SYSTEM as an owner.

> > If you think this is bad behavior, lobby on emacs-devel to allow some
> > kind of user options for ignoring these errors (which means you don't
> > care about security of access to your files).
> 
> I don't think that a user option is the way to go if it's going to be 
> off by default.
> 
> Maybe don't expect the user to customize its value, and bind it to t in 
> certain functions, like backup-buffer-copy, instead?

I will let others answer that.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 13298 <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 22:33:04 +0400

On 29.12.2012 21:28, Eli Zaretskii wrote:
>> Why doesn't Emacs try to show the elevation dialog, anyway?
>
> The elevation dialog comes from Windows, when it does.  Applications
> don't show it, they just can trigger it by performing operations that
> require elevation.  But UAC behaves strangely when Administrators are
> involved.

I'm not familiar with Windows API, but I think there's a specific way to 
request the elevation. For example, foobar2000 installer starts up 
normally, but shows the elevation dialog when you click on the "Update" 
button, with the same standard shield icon as in Explorer.

>>>> Like I described, I don't think my situation is exceptional, so seeing
>>>> the error messages is misleading.
>>>
>>> Why misleading?  We asked Emacs to preserve the ACLs of the original
>>> file, and it couldn't.  Shouldn't the user be informed about that?
>>
>> It leads me to believe that there's either something wrong with my
>> system, or Emacs configuration, whereas I don't know why I should care
>> that the backup function doesn't correctly set the file ownership.
>
> You could try taking care of this issue by manually taking ownership
> of the C:\Users\Gutov directory and all of its files and
> subdirectories.  Setting the owner of C:\Users\Gutov to either your
> user or the Administrators group will probably resolve the problem.

Changing the owner of the directory itself didn't do it (I didn't check 
"replace on all subcontainers"), but changing the owner of each 
problematic file did it. Thanks!

> Doing the former, i.e. setting your user as the owner, sounds like TRT
> to me anyway, it doesn't make sense to me to have SYSTEM as an owner.

If the owner is Administrators, the error is the same, so SYSTEM is not 
the problem here.

>>> If you think this is bad behavior, lobby on emacs-devel to allow some
>>> kind of user options for ignoring these errors (which means you don't
>>> care about security of access to your files).
>>
>> I don't think that a user option is the way to go if it's going to be
>> off by default.
>>
>> Maybe don't expect the user to customize its value, and bind it to t in
>> certain functions, like backup-buffer-copy, instead?
>
> I will let others answer that.

To expand on this idea, if you were to get elevation to work, the 
variable would control whether you would show the user the elevation 
dialog if they have insufficient rights, or just fail silently.

I can't imagine, for example, anyone thinking that showing the elevation 
dialog (or several) during Emacs shutdown is a good idea.

But if I'm a security-conscious Windows user,
a) I'm not going to run Emacs "As Administrator",
b) If I'm assigning access rights to a file, I'd prefer to see the 
elevation dialog instead of just the error message.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 13298-done <at> debbugs.gnu.org
Subject: Re: bug#13298: 24.3.50; Cannot write backup file;
	backing up in ~\.emacs.d\%backup%~
Date: Sat, 29 Dec 2012 21:11:10 +0200

> Date: Sat, 29 Dec 2012 22:33:04 +0400
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 13298 <at> debbugs.gnu.org
> 
> On 29.12.2012 21:28, Eli Zaretskii wrote:
> >> Why doesn't Emacs try to show the elevation dialog, anyway?
> >
> > The elevation dialog comes from Windows, when it does.  Applications
> > don't show it, they just can trigger it by performing operations that
> > require elevation.  But UAC behaves strangely when Administrators are
> > involved.
> 
> I'm not familiar with Windows API, but I think there's a specific way to 
> request the elevation. For example, foobar2000 installer starts up 
> normally, but shows the elevation dialog when you click on the "Update" 
> button, with the same standard shield icon as in Explorer.

I'm guessing that this foobar2000 restarts itself with elevated level
when you click on "Update".  That's the only way I know of to request
elevation programmatically -- it can only be done at process start
time.  Once the process started, it has its privileges in the process
token, and that cannot be changed.

> > You could try taking care of this issue by manually taking ownership
> > of the C:\Users\Gutov directory and all of its files and
> > subdirectories.  Setting the owner of C:\Users\Gutov to either your
> > user or the Administrators group will probably resolve the problem.
> 
> Changing the owner of the directory itself didn't do it (I didn't check 
> "replace on all subcontainers"), but changing the owner of each 
> problematic file did it. Thanks!

OK, so I guess I can now close this bug.  Thanks for helping me test
the solution.

Previous Next

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