GNU bug report logs -
#41463
27.0.91; ACL error on Windows when trying to save file
Previous Next
Reported by: Lars Ljung <lars <at> matholka.se>
Date: Fri, 22 May 2020 17:48:02 UTC
Severity: normal
Found in version 27.0.91
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41463 in the body.
You can then email your comments to 41463 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41463
; Package
emacs
.
(Fri, 22 May 2020 17:48:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lars Ljung <lars <at> matholka.se>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 22 May 2020 17:48:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I get the following error when trying to save a specific file:
Saving file h:/some/file.txt...
file-extended-attributes: Getting ACLs: Input/output error, h:/some/file.txt
This is unexpected since both Emacs 26.3 and notepad.exe are able to
write to this file. Even though I also get an error when using the
Get-Acl command in PowerShell.
In GNU Emacs 27.0.91 (build 2, x86_64-w64-mingw32)
Repository revision: 4b9fbdb5a713745dfdb13042e33ba2345e6860e1
Repository branch: emacs-27
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Enterprise (v10.0.1909.18363.836)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure --prefix=/c/emacs/emacs-27.1 --without-compress-install
--disable-build-details --without-pop LDFLAGS=-shared-libgcc'
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY W32NOTIFY ACL GNUTLS
LIBXML2 HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER
LCMS2 GMP
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: cp1252
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41463
; Package
emacs
.
(Fri, 22 May 2020 19:09:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 41463 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ljung <lars <at> matholka.se>
> Date: Fri, 22 May 2020 19:47:39 +0200
>
> I get the following error when trying to save a specific file:
>
> Saving file h:/some/file.txt...
> file-extended-attributes: Getting ACLs: Input/output error, h:/some/file.txt
>
> This is unexpected since both Emacs 26.3 and notepad.exe are able to
> write to this file. Even though I also get an error when using the
> Get-Acl command in PowerShell.
Please report all the details: the ACLs and the owner of that file,
and your user's name and group. It is impossible to investigate this
without those details.
There was no change in handling of ACLs between Emacs 26 and 27, but
some file-related operations now signal an error instead of silently
failing. I'm guessing you bumped into one such situation.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41463
; Package
emacs
.
(Fri, 22 May 2020 21:28:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 41463 <at> debbugs.gnu.org (full text, mbox):
Den 2020-05-22 kl. 21:08, skrev Eli Zaretskii:
> Please report all the details: the ACLs and the owner of that file,
> and your user's name and group. It is impossible to investigate this
> without those details.
>
> There was no change in handling of ACLs between Emacs 26 and 27, but
> some file-related operations now signal an error instead of silently
> failing. I'm guessing you bumped into one such situation.
Now I think that this happens because H: is a network drive that is
marked as "available offline". The problem goes away if I reconnect to
the company network, and it comes back when I go offline again.
I traced this to acl_get_file() in w32.c where GetLastError() returns
50, i.e. ERROR_NOT_SUPPORTED.
I hope this helps.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41463
; Package
emacs
.
(Sat, 23 May 2020 05:44:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 41463 <at> debbugs.gnu.org (full text, mbox):
> Cc: 41463 <at> debbugs.gnu.org
> From: Lars Ljung <lars <at> matholka.se>
> Date: Fri, 22 May 2020 23:27:11 +0200
>
> Now I think that this happens because H: is a network drive that is
> marked as "available offline". The problem goes away if I reconnect to
> the company network, and it comes back when I go offline again.
>
> I traced this to acl_get_file() in w32.c where GetLastError() returns
> 50, i.e. ERROR_NOT_SUPPORTED.
Thanks. Does the patch below fix this problem?
diff --git a/src/w32.c b/src/w32.c
index 62c53fd..4d351dd 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -6409,6 +6409,8 @@ acl_get_file (const char *fname, acl_type_t type)
be encoded in the current ANSI codepage. */
|| err == ERROR_INVALID_NAME)
errno = ENOENT;
+ else if (err == ERROR_NOT_SUPPORTED)
+ errno = ENOTSUP;
else
errno = EIO;
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41463
; Package
emacs
.
(Sat, 23 May 2020 05:53:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 41463 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 23 May 2020 08:43:40 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 41463 <at> debbugs.gnu.org
>
> > I traced this to acl_get_file() in w32.c where GetLastError() returns
> > 50, i.e. ERROR_NOT_SUPPORTED.
>
> Thanks. Does the patch below fix this problem?
Actually, please use this more thorough patch instead:
diff --git a/src/w32.c b/src/w32.c
index 62c53fd..78e75f0 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -6398,7 +6398,15 @@ acl_get_file (const char *fname, acl_type_t type)
if (!get_file_security (fname, si, psd, sd_len, &sd_len))
{
xfree (psd);
- errno = EIO;
+ err = GetLastError ();
+ if (err == ERROR_NOT_SUPPORTED)
+ errno = ENOTSUP;
+ else if (err == ERROR_FILE_NOT_FOUND
+ || err == ERROR_PATH_NOT_FOUND
+ || err == ERROR_INVALID_NAME)
+ errno = ENOENT;
+ else
+ errno = EIO;
psd = NULL;
}
}
@@ -6409,6 +6417,8 @@ acl_get_file (const char *fname, acl_type_t type)
be encoded in the current ANSI codepage. */
|| err == ERROR_INVALID_NAME)
errno = ENOENT;
+ else if (err == ERROR_NOT_SUPPORTED)
+ errno = ENOTSUP;
else
errno = EIO;
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41463
; Package
emacs
.
(Sat, 23 May 2020 07:14:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 41463 <at> debbugs.gnu.org (full text, mbox):
Den 2020-05-23 kl. 07:52, skrev Eli Zaretskii:
>> Date: Sat, 23 May 2020 08:43:40 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 41463 <at> debbugs.gnu.org
>>
>>> I traced this to acl_get_file() in w32.c where GetLastError() returns
>>> 50, i.e. ERROR_NOT_SUPPORTED.
>>
>> Thanks. Does the patch below fix this problem?
>
> Actually, please use this more thorough patch instead:
That does the trick, thanks :)
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 23 May 2020 07:41:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Lars Ljung <lars <at> matholka.se>
:
bug acknowledged by developer.
(Sat, 23 May 2020 07:41:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 41463-done <at> debbugs.gnu.org (full text, mbox):
> Cc: 41463 <at> debbugs.gnu.org
> From: Lars Ljung <lars <at> matholka.se>
> Date: Sat, 23 May 2020 09:12:57 +0200
>
> Den 2020-05-23 kl. 07:52, skrev Eli Zaretskii:
> >> Date: Sat, 23 May 2020 08:43:40 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >> Cc: 41463 <at> debbugs.gnu.org
> >>
> >>> I traced this to acl_get_file() in w32.c where GetLastError() returns
> >>> 50, i.e. ERROR_NOT_SUPPORTED.
> >>
> >> Thanks. Does the patch below fix this problem?
> >
> > Actually, please use this more thorough patch instead:
>
> That does the trick, thanks :)
Great, thanks. I installed the fix on the emacs-27 branch, and I'm
therefore marking this bug done.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 20 Jun 2020 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.