GNU bug report logs - #75938
31.0.50; Temporary file-names overflowing MAX_PATH characters

Previous Next

To reply to this bug, email your comments to 75938 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: arthur miller <arthur.miller <at> live.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 31.0.50; Temporary file-names overflowing MAX_PATH characters
Date: Thu, 30 Jan 2025 03:45:43 +0000

[Message part 1 (text/plain, inline)]

I am not sure if this is a bug or not; so do what you want with this.

It is fully possibly to create names that are not valid as file names,
via make-temp-name and make-temp-file, which are frontend for the
make-temp-file-internal function. For example:

(make-temp-name (make-string 1024 ?a))

will succeed without problems, but of course:

(make-temp-file (make-string 1024 ?a))

will fail, later on when it actually tries to create the file.

Attached is a suggested fix; the idea is to save the unnecessary trip to
the OS; it signals error if the total file name length is longer than
MAX_PATH.

I don't know if it is a feature to have temp-names longer than certain
length, if it is than OK; this is more of a question/suggestion than a
bug report.

[Message part 2 (text/html, inline)]

[0001-Ensure-temporary-file-names-have-valid-lengths.patch (application/octet-stream, attachment)]

Message #8 received at 75938 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: arthur miller <arthur.miller <at> live.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 75938 <at> debbugs.gnu.org
Subject: Re: bug#75938: 31.0.50;
 Temporary file-names overflowing MAX_PATH characters
Date: Thu, 30 Jan 2025 09:41:18 +0200

> From: arthur miller <arthur.miller <at> live.com>
> Date: Thu, 30 Jan 2025 03:45:43 +0000
> 
> I am not sure if this is a bug or not; so do what you want with this.
> 
> It is fully possibly to create names that are not valid as file names,
> via make-temp-name and make-temp-file, which are frontend for the
> make-temp-file-internal function. For example:
> 
> (make-temp-name (make-string 1024 ?a))
> 
> will succeed without problems, but of course:
> 
> (make-temp-file (make-string 1024 ?a))
> 
> will fail, later on when it actually tries to create the file.
> 
> Attached is a suggested fix; the idea is to save the unnecessary trip to
> the OS; it signals error if the total file name length is longer than
> MAX_PATH.
> 
> I don't know if it is a feature to have temp-names longer than certain
> length, if it is than OK; this is more of a question/suggestion than a
> bug report.

I think the idea is that the call to make_uninit_string will signal an
error if its argument exceeds STRING_BYTES_MAX, and the relevant
system library functions will error with ENAMETOOLONG if they cannot
support such long file names.

Adding Paul to the discussion.

Message #11 received at 75938 <at> debbugs.gnu.org (full text, mbox):

From: arthur miller <arthur.miller <at> live.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "75938 <at> debbugs.gnu.org" <75938 <at> debbugs.gnu.org>
Subject: Sv: bug#75938: 31.0.50; Temporary file-names overflowing MAX_PATH
 characters
Date: Thu, 30 Jan 2025 16:30:27 +0000

[Message part 1 (text/plain, inline)]

> I think the idea is that the call to make_uninit_string will signal an
> error if its argument exceeds STRING_BYTES_MAX, and the relevant
> system library functions will error with ENAMETOOLONG if they cannot
> support such long file names.

Yes, it does that. It is a large number though; but Windows does is not creating
it thugh:

Debugger entered--Lisp error: (file-missing "Creating file with prefix" "No such file or directory" "r:/Temp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")
  make-temp-file("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")
  eval((make-temp-file (make-string 1024 97)) nil)
  ielm-eval-input(#("(make-temp-file  (make-string 1024 ?a))" 0 39 (fontified t)) nil)
  ielm-send-input(nil)
  ielm-return()
  funcall-interactively(ielm-return)
  command-execute(ielm-return)

That only dichotomy is that make-temp-name will produce a string, but that string
will not be suitable as a file name, but that perhaps is a feature? That was
also a part I was asking about. Perhaps, since the docs are already declaring
that using this function and later trying to create a file with that name asks
for troubles, perhaps it should be obsoleted?

By the way, while playing with this, I have discovered a very easy way to
blow-up stack: (make-temp-name (make-string (* 1024 1024 1024) ?a)). Is there
any way that byte-compiler or lisp-reader could detect such "innocent" code, or
 is it only code-review that can discover something like that?

Just a curious question, sorry for regressing.

[Message part 2 (text/html, inline)]

Message #14 received at 75938 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, arthur miller <arthur.miller <at> live.com>
Cc: 75938 <at> debbugs.gnu.org
Subject: Re: bug#75938: 31.0.50; Temporary file-names overflowing MAX_PATH
 characters
Date: Thu, 30 Jan 2025 11:58:06 -0800

On 1/29/25 23:41, Eli Zaretskii wrote:
> I think the idea is that the call to make_uninit_string will signal an
> error if its argument exceeds STRING_BYTES_MAX, and the relevant
> system library functions will error with ENAMETOOLONG if they cannot
> support such long file names.

Yes, that's the idea. There is at least one system (GNU/Hurd) which does 
not have a path limit.

On 1/30/25 08:30, arthur miller wrote:

>  make-temp-name will produce a string, but that string
> will not be suitable as a file name, but that perhaps is a feature?

Yes, because make-temp-name cannot always predict exactly which names 
are allowed. Some file systems don't allow encoding errors in file 
names, for example. When the manual says that make-temp-name "generates 
a string that might be a unique file name", it means that the string 
might not be unique and might not be a file name.


> since the docs are already declaring
> that using this function and later trying to create a file with that name asks
> for troubles, perhaps it should be obsoleted?

The first step in any such move would be to modify Emacs itself so that 
it never calls make-temp-name. Is that a project you could take on?



> By the way, while playing with this, I have discovered a very easy way to
> blow-up stack: (make-temp-name (make-string (* 1024 1024 1024) ?a)). Is there
> any way that byte-compiler or lisp-reader could detect such "innocent" code, or
>  is it only code-review that can discover something like that?

I don't see much point in trying to detect that particular problem 
statically. Not sure what you mean by "blow-up stack": what were the 
symptoms?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.