GNU bug report logs - #17938
Very long path name can not handle in windows mingw emacs.

Previous Next

Package: emacs;

Reported by: Masamichi HOSODA <trueroad <at> sea.plala.or.jp>

Date: Fri, 4 Jul 2014 18:09:04 UTC

Severity: wishlist

Tags: wontfix

Done: Stefan Kangas <stefan <at> marxist.se>

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 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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Masamichi HOSODA <trueroad <at> sea.plala.or.jp>
To: bug-gnu-emacs <at> gnu.org
Subject: Very long path name can not handle in windows mingw emacs.
Date: Sat, 05 Jul 2014 00:05:54 +0900 (JST)
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):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Masamichi HOSODA <trueroad <at> sea.plala.or.jp>
Cc: 17938 <at> debbugs.gnu.org
Subject: Re: bug#17938: Very long path name can not handle in windows mingw
 emacs.
Date: Fri, 04 Jul 2014 23:07:21 +0300
> 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):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Masamichi HOSODA <trueroad <at> sea.plala.or.jp>, 17938 <at> debbugs.gnu.org
Subject: Re: bug#17938: Very long path name can not handle in windows mingw
 emacs.
Date: Wed, 29 Jun 2022 08:12:23 -0700
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.