bug#17938: Very long path name can not handle in windows mingw emacs.

bug#17938: Very long path name can not handle in windows mingw emacs.

[Masamichi HOSODA]

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.

bug#17938: Very long path name can not handle in windows mingw emacs.

[Eli Zaretskii]

> Date: Sat, 05 Jul 2014 00:05:54 +0900 (JST)
> From: Masamichi HOSODA <trueroad@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.

bug#17938: Very long path name can not handle in windows mingw emacs.

[Stefan Kangas]

tags 17938 + wontfix
close 17938
thanks

Eli Zaretskii <eliz@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.