bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Kangas
Subject: bug#17938: Very long path name can not handle in windows mingw emacs.
Date: Wed, 29 Jun 2022 08:12:23 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]