bug#13298: 24.3.50; Cannot write backup file; backing up in ~\.emacs.d\%backup%~

[Dmitry Gutov]

On 29.12.2012 20:59, Eli Zaretskii wrote:
> > Date: Sat, 29 Dec 2012 20:05:23 +0400
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > CC: 13298@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@yandex.ru>
> > > > CC: 13298@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@yandex.ru>
> > > > > > CC: 13298@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?