GNU bug report logs -
#21699
24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc
Previous Next
Reported by: Eli Barzilay <eli <at> barzilay.org>
Date: Sun, 18 Oct 2015 04:36:02 UTC
Severity: normal
Found in version 24.5
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #11 received at 21699 <at> debbugs.gnu.org (full text, mbox):
On Sun, Oct 18, 2015 at 12:01 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> 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"?
Yes, I do have customizations. Overall I'm not doing anything that
should be done -- though I'm guessing that not many people get to that
situation. The main thing in my setup is that backups are done by
copying the file into a single directory for backups -- and in the
problem case the backup is on a local windows directory when the
original file is coming from a remote mount (on linux). But the bugs
are easy to see:
1. `with-demoted-errors' is used in a bunch of places without a format
string. This is not a bug since the macro supports the case of a
non-literal-string being the first expression, but's for legacy, so
it's either better to add that format string, or the macro should
support that without qualifying it as a legacy feature.
2. The `set-file-extended-attributes' function always returns nil, which
is a proper bug:
- In `backup-buffer-copy' its return value is used as if it indicates
whether it succeeded -- that's currently broken because it always
returns nil.
- It's also used in `basic-save-buffer' -- but there its result is
not used, and the code looks like it's expecting it to throw an
error on failure.
- It's also used in `basic-save-buffer-2', in a `with-demoted-errors'
The commit message that I pointed to makes me think that it's
expected to return nil on failure -- so it should be fixed to do
that. Another solution would be if it's expected to throw an error
when it fails, and in this case the first use is broken and should
not look at its result.
3. The third problem happens *if* the solution to #2 is to make it
return a meaningful result. In that case, the problem I'll run into
is that on windows my extended modes include
(selinux nil nil nil nil)
which I'm guessing is because there's no selinux support, but then
`set-file-selinux-context' should not fail when getting a value of
(nil nil nil nil).
4. The last problem of chmod-ing failing after setting the windows acl
is probably better to defer after resolving the above.
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
This bug report was last modified 3 years and 31 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.