unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Eli Barzilay <eli@barzilay.org>
Cc: 21699@debbugs.gnu.org
Subject: bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc
Date: Sun, 18 Oct 2015 19:01:36 +0300	[thread overview]
Message-ID: <83wpuki2sf.fsf@gnu.org> (raw)
In-Reply-To: <22051.8546.40000.221633@gargle.gargle.HOWL>

> From: Eli Barzilay <eli@barzilay.org>
> Date: Sun, 18 Oct 2015 00:34:42 -0400
> 
> (There are potentially multiple bugs here, I'll mark them as [n].)
> 
> After switching to 24.5 I started to see warnings like:
> 
>     Cannot write backup file; backing up in ~/.emacs.d/%backup%~
> 
> when saving a file on a remote directory (running on Windows, remote
> is on Linux, but this is unlikely to be relevant).
> 
> I tracked this to `backup-buffer-copy', which has a seemingly bad use
> of `with-demoted-errors'.

Do you mean to say that backup-buffer-copy fails in your case?  If so,
it means you have some customizations, or maybe the way your volume is
mounted causes backup-buffer-copy be called.  It isn't normally called
in "emacs -Q" and with local files, AFAICT.

Is that what happens in your case?

Do you see the problem in "emacs -Q"?

> The next suspect was `set-file-extended-attributes'.  This code comes
> from commit ccad023bc3c70fc8368c00f7ed2f5ec947a4260d (2012-12-29), and
> following the description there, I think that there's a bug in this
> function: it has a single `dolist' which would always return nil,
> which means that putting it in the `and' of `backup-buffer-copy' makes
> the code always think that there was a failure.  Instead, there should
> be some flag to be used in the loop to keep track of the `and' of all
> of the results [2].  (Or maybe there's some andmap/every/... function
> that does it more idiomatically.)
> 
> Next comes `set-file-selinux-context', which might have a problem.
> It's documentation says:
> 
>     This function does nothing and returns nil if SELinux is disabled,
>     or if Emacs was not compiled with SELinux support.
> 
> which I assume is my case since I'm running on Windows.  It is called
> with (nil nil nil nil) which I'm guessing is some no-information-
> since-we-don't-have-selinux thing -- but in that case,
> `set-file-selinux-context' should not return nil when it's getting
> that value.  So something is definitely broken here [3], either it
> shouldn't return nil, or it shouldn't be called (avoid adding that
> 4xnil value to the extended-attributes, or avoid calling
> `set-file-selinux-context' with that value), and possibly there should
> be an explicit no-info value.
> 
> Finally, after the above problem makes it think that there was a
> failure, it uses `set-file-modes' with the backup file, and that
> throws an error for the backup file:
> 
>     (file-error "Doing chmod" "permission denied" "...path-to-backup...")
> 
> My setup is to have a single (local) directory for backups, so this
> might be some result of applying the windows acl thing first, copying
> the acl of the remote file to the one of the local backup.  Windows
> shows that the file permissions for Everyone are: "Read & Execute" and
> "Read", so that might be the problem.  I'm not sure how this whole
> thing will look like, but it might be a problem to apply the acls this
> way, so this problem might require some additional flag that allows
> people to avoid copying the acls to the backups.

Thanks for looking into this.

I don't think there are so many problems in those functions.  I
suggest to step with Edebug into backup-buffer and its subroutines, or
maybe just into backup-buffer-copy, if you are sure it's the failing
function, and establish for sure which of them fails and why.  Then we
could take it from there.

My first guess would be some snafu in Windows permissions caused by
the method you used to mount the GNU/Linux volume.  But before I start
asking you for further information based on that hypothesis, I'd like
to be sure this is indeed the cause of your problems.





  reply	other threads:[~2015-10-18 16:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-18  4:34 bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc Eli Barzilay
2015-10-18 16:01 ` Eli Zaretskii [this message]
2015-10-18 21:05   ` Eli Barzilay
2015-10-19  5:10     ` Eli Zaretskii
2015-10-19  7:57       ` Eli Barzilay
2015-10-19  8:23         ` Eli Zaretskii
2015-10-19  9:03           ` Eli Barzilay
2015-10-19  9:09             ` Eli Zaretskii
2015-10-19  9:14               ` Eli Barzilay
2015-10-19  6:14 ` bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc [set-file-extended-attributes] Eli Barzilay
2015-10-19  6:38   ` Eli Zaretskii
2015-10-19  6:50     ` Eli Zaretskii
2015-10-19  7:09       ` Eli Zaretskii
2015-10-19  7:50         ` Eli Barzilay
2015-10-19  8:04           ` Eli Zaretskii
2015-10-19  9:10             ` Eli Barzilay
2015-10-19  9:22               ` Eli Zaretskii
2015-10-19  9:47                 ` Eli Barzilay
2015-10-19 10:14                   ` Eli Zaretskii
2015-10-22  5:43                     ` Eli Barzilay
2015-10-23  8:25                       ` Eli Zaretskii
2022-04-22 13:27                         ` bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83wpuki2sf.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=21699@debbugs.gnu.org \
    --cc=eli@barzilay.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).