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
View this message in rfc822 format
On Mon, Oct 19, 2015 at 6:14 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Thanks. I'll let others to express opinions on this alternative vs
> the one I committed. The difference is what happens when all the
> attribute values are "null" values: your version returns t in that
> case, and I'm not sure that's correct, see below.
Ah, you're talking about this code from `backup-buffer-copy':
(unless (and extended-attributes
(with-demoted-errors
(set-file-extended-attributes to-name extended-attributes)))
...)
In that case, I think that my slightly earlier fix which made
`file-extended-attributes' drop "null" values is actually fine: it means
that in the above snipped `extended-attributes' will be nil, and the
chmod code will run. There is another use of a similar pattern (look
for an "If set-file-extended-attributes fails" comment which appears in
both places) where this second one should also have the same `and'.
(The current state is messy anyway, since with your current fix, the
`and' in the above is not needed, and anyway, `extended-attributes' is
never nil.)
FWIW, there is no real loss of information for doing that:
`extended-attributes' currently adds acl and selinux entries always,
with my fix (of dropping the no-info values) you can tell when there was
no information for acl/selinux just by the fact that there is no such
element in the `extended-attributes' result.
--
((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.