bug#21699: 24.5; Bug in backup-buffer-copy and/or set-file-extended-attributes etc

[Eli Barzilay <eli@barzilay.org>]

On Sun, Oct 18, 2015 at 12:01 PM, Eli Zaretskii <eliz@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!