GNU bug report logs -
#17938
Very long path name can not handle in windows mingw emacs.
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17938 in the body.
You can then email your comments to 17938 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#17938
; Package
emacs
.
(Fri, 04 Jul 2014 18:09:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Masamichi HOSODA <trueroad <at> sea.plala.or.jp>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 04 Jul 2014 18:09:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello.
Very long path name files can not handle in windows mingw emacs.
GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200)
GNU Emacs 24.3.92.1 (x86_64-w64-mingw32)
etc.
It is a path name over about 260 characters.
The files and folders are not displayed in dired.
So they are unable to open.
When you drag and drop the folder from explorer, emacs shows a message like
"Directory /long/path/name/folder inaccessible or nonexistent".
I think that the following is the cause.
In the mingw environment, MAX_PATH is defined as 260.
Emacs source src/w32.c uses MAX_PATH for filename buffers.
However, NTFS (NT File System) can handle longer path name than 260 characters.
Thank you.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17938
; Package
emacs
.
(Fri, 04 Jul 2014 20:08:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 17938 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 05 Jul 2014 00:05:54 +0900 (JST)
> From: Masamichi HOSODA <trueroad <at> sea.plala.or.jp>
>
> Very long path name files can not handle in windows mingw emacs.
>
> GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200)
> GNU Emacs 24.3.92.1 (x86_64-w64-mingw32)
> etc.
>
> It is a path name over about 260 characters.
> The files and folders are not displayed in dired.
> So they are unable to open.
> When you drag and drop the folder from explorer, emacs shows a message like
> "Directory /long/path/name/folder inaccessible or nonexistent".
>
>
> I think that the following is the cause.
> In the mingw environment, MAX_PATH is defined as 260.
> Emacs source src/w32.c uses MAX_PATH for filename buffers.
The use of MAX_PATH is on purpose. It is not an accident, and
defining it to a larger value will not solve the problem, see below.
> However, NTFS (NT File System) can handle longer path name than 260 characters.
Yes, NTFS can handle file names that are longer than 260 characters.
However, that feature comes at a high price. First, every file name
needs to be converted to the "\\?\X\foo" format, before handing it to
system APIs and C library functions that accept file names. Next,
some standard functions cannot handle such names (examples: _wchdir,
_wstat), so they need to be rewritten using other, lower-level
primitives. Finally, most programs and utilities that come with
Windows cannot handle these files. The most striking example is the
Windows Explorer, but since we are talking about Emacs, it is
worthwhile to remember that no compiler, linker, or utility like Diff
or Patch or Coreutils can handle such files. So you cannot copy,
rename, or delete such files, except by the program which created
them; and you cannot compile them. IOW, they are all but useless.
For these reasons, I think that support for such file names is very
low priority for Emacs on Windows.
Thanks.
Severity set to 'wishlist' from 'normal'
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 04 Jul 2014 20:10:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#17938
; Package
emacs
.
(Wed, 29 Jun 2022 15:13:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 17938 <at> debbugs.gnu.org (full text, mbox):
tags 17938 + wontfix
close 17938
thanks
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I think that the following is the cause.
>> In the mingw environment, MAX_PATH is defined as 260.
>> Emacs source src/w32.c uses MAX_PATH for filename buffers.
>
> The use of MAX_PATH is on purpose. It is not an accident, and
> defining it to a larger value will not solve the problem, see below.
>
>> However, NTFS (NT File System) can handle longer path name than 260 characters.
>
> Yes, NTFS can handle file names that are longer than 260 characters.
> However, that feature comes at a high price. First, every file name
> needs to be converted to the "\\?\X\foo" format, before handing it to
> system APIs and C library functions that accept file names. Next,
> some standard functions cannot handle such names (examples: _wchdir,
> _wstat), so they need to be rewritten using other, lower-level
> primitives. Finally, most programs and utilities that come with
> Windows cannot handle these files. The most striking example is the
> Windows Explorer, but since we are talking about Emacs, it is
> worthwhile to remember that no compiler, linker, or utility like Diff
> or Patch or Coreutils can handle such files. So you cannot copy,
> rename, or delete such files, except by the program which created
> them; and you cannot compile them. IOW, they are all but useless.
>
> For these reasons, I think that support for such file names is very
> low priority for Emacs on Windows.
I think this sounds like a wontfix, so I'm marking it as such and
closing this bug. Thanks.
Added tag(s) wontfix.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Wed, 29 Jun 2022 15:13:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
17938 <at> debbugs.gnu.org and Masamichi HOSODA <trueroad <at> sea.plala.or.jp>
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Wed, 29 Jun 2022 15:13: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
.
(Thu, 28 Jul 2022 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 244 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.