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

[Dmitry Gutov <dgutov@yandex.ru>]

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?