GNU bug report logs -
#74150
ESHELL support for executables that are NTFS file system reparse points
Previous Next
Reported by: dnym <at> duck.com
Date: Fri, 1 Nov 2024 00:31:01 UTC
Severity: normal
Merged with 71655
Done: Jim Porter <jporterbugs <at> gmail.com>
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 74150 in the body.
You can then email your comments to 74150 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#74150
; Package
emacs
.
(Fri, 01 Nov 2024 00:31:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
dnym <at> duck.com
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 01 Nov 2024 00:31:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
DESCRIPTION OF THE PROBLEM:
None of the executables inside
C:/Users/Me/AppData/Local/Microsoft/WindowsApps
can be run from the command line under eshell.
The error I receive when trying to run any of these executables looks like:
Opening input file: Invalid argument,
C:/Users/Me/AppData/Local/Microsoft/WindowsApps/notepad.exe
What I've been able to glean so far is that these executables, all of which
are 0k in size, are in fact NTFS reparse points which contain metadata
that is supposed to be read by the appropriate filter driver.
In a cmd.exe or pwsh.exe console under windows, I can run this notepad.exe
executable from the command line without any problem. So I think the
issue has to do with eshell not being able to handle file system
objects that are NTFS reparse points.
Could not find any additional information on this by searching the web.
An obvious workaround is to call cmd.exe /C notepad.exe from inside eshell,
but I would like to better understand why eshell cannot call any of
these executables directly.
Should this be considered a bug or a feature?
In GNU Emacs 29.4 (build 2, x86_64-w64-mingw32) of 2024-06-23 built on
fv-az1388-367
Windowing system distributor 'Microsoft Corp.', version 10.0.22631
System Description: Microsoft Windows 10 Pro (v10.0.2009.22631.4391)
Configured using:
'configure --prefix=/mingw64 --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --with-modules --without-dbus
--without-compress-install --with-tree-sitter
--with-native-compilation=aot 'CFLAGS=-march=nocona -msahf
-mtune=generic -O2 -pipe -fstack-protector-strong
-fno-optimize-sibling-calls -Wno-error=implicit-function-declaration'
CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1 'LDFLAGS= -lpthread''
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LIBXML2 MODULES NATIVE_COMP NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
Important settings:
value of $LANG: ENU
locale-coding-system: cp1252
Major mode: Lisp Interaction
Minor modes in effect:
shell-dirtrack-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-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
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils tramp-sh tramp tramp-loaddefs
trampver tramp-integration tramp-compat parse-time iso8601 time-date
format-spec auth-source eieio eieio-core password-cache json map
byte-opt em-unix em-term term shell ehelp em-script em-prompt em-ls
em-hist em-pred em-glob em-extpipe em-cmpl em-dirs esh-var pcomplete
comint ansi-osc ansi-color ring em-basic em-banner em-alias esh-mode
eshell esh-cmd generator cl-loaddefs comp comp-cstr warnings icons
subr-x rx cl-seq cl-macs gv cl-extra help-mode bytecomp byte-compile
cl-lib esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups
esh-util files-x rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads
w32notify w32 multi-tty make-network-process native-compile emacs)
Memory information:
((conses 16 130718 7658)
(symbols 48 10843 0)
(strings 32 35011 2189)
(string-bytes 1 1103678)
(vectors 16 24409)
(vector-slots 8 478478 13710)
(floats 8 52 45)
(intervals 56 408 0)
(buffers 984 11))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#74150
; Package
emacs
.
(Fri, 01 Nov 2024 01:06:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 74150 <at> debbugs.gnu.org (full text, mbox):
unarchive 71655
forcemerge 71655 74150
thanks
On 10/31/2024 5:18 PM, dnym--- via Bug reports for GNU Emacs, the Swiss
army knife of text editors wrote:
> DESCRIPTION OF THE PROBLEM:
>
> None of the executables inside
> C:/Users/Me/AppData/Local/Microsoft/WindowsApps
> can be run from the command line under eshell.
>
> The error I receive when trying to run any of these executables looks like:
>
> Opening input file: Invalid argument,
> C:/Users/Me/AppData/Local/Microsoft/WindowsApps/notepad.exe
>
> What I've been able to glean so far is that these executables, all of which
> are 0k in size, are in fact NTFS reparse points which contain metadata
> that is supposed to be read by the appropriate filter driver.
Thanks for the report. This is bug#71655[1], which is already fixed in
Emacs 30, so marking as a dupe.
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71655
Forcibly Merged 71655 74150.
Request was from
Jim Porter <jporterbugs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 01 Nov 2024 01:06:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 29 Nov 2024 12:24:18 GMT)
Full text and
rfc822 format available.
This bug report was last modified 204 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.