Error on opening a pipe to an external program: couldn't create error file for command: permission denied

[Arjen Markus]

Hi everyone,

I am confronted with this mysterious error message:

couldn't create error file for command: permission denied

when running the command [open "|$argv" r] to capture the output of a program.

The actual Tcl program has been around for quite a few years and I have never before seen this error message. Searching the web did not result in any suggestions for solving this that actually solved it. The temporary directories (env(TMP) and env(TEMP) - actually the same directory) are writeable in any case.

This occurs on Windows 10.

Any suggestions?

Regards,

Arjen

[Harald Oehlmann]

I suppose, the error message is coming from the called program...

[Arjen Markus]

No, it is not. I even got when I tried to run a non-existing program that way ;). It seems to be part of [exec]. At least that is the impression I got from the various discussions on the Internet that I found.

The solutions that were suggested had to do with the temporary directory - but that turned out to be not the problem, at least I could write ordinary files in that directory.

Regards,

Arjen

[Ralf Fassel]

* Arjen Markus <arjen.m...@gmail.com>

This seems to originate (tcl 8.6.9) in

generic/tclPipe.c:838: "couldn't create error file for command: %s",

/*
* Set up the standard error output sink for the pipeline, if
* requested. Use a temporary file which is opened, then deleted.
* Could potentially just use pipe, but if it filled up it could
* cause the pipeline to deadlock: we'd be waiting for processes
* to complete before reading stderr, and processes couldn't
* complete because stderr was backed up.
*/
errorFile = TclpCreateTempFile(NULL);
if (errorFile == NULL) {
Tcl_SetObjResult(interp, Tcl_ObjPrintf(
"couldn't create error file for command: %s",
Tcl_PosixError(interp)));
goto error;
}
*errFilePtr = errorFile;

So the question is why TclpCreateTempFile(NULL) fails.

On Windows, this is win/tclWinPipe.c:650:TclpCreateTempFile, which can
fail in this context for several reasons:

- static int TempFileName() fails (MAX_PATH, permissions etc)
- windows API CreateFile() fails (MAX_PATH, permissions etc)
- TclFile TclWinMakeFile() fails (not possible, see code)

Is length of your path env(TMP) close to MAX_PATH?
Can you recompile and run TCL to have diagnostic output in those places?

HTH
R'

[Arjen Markus]

On Tuesday, August 13, 2019 at 5:44:41 PM UTC+2, Ralf Fassel wrote:
> * Arjen Markus

I checked the TMP and TEMP environment variables - they are pointing to the same directory and I can open files in there and write to them. That is no particular problem. The Tcl/Tk shell in question is a tclkit, patchlevel 8.6.4.

(By the way, I have seen postings dating back to 1997 (!) that contain the same error message, so it is not a new text)

The path is something like c:\users\user\tmp - so nowhere near MAX_PATH in length.

I could try building a patched version, but I have no direct access to the PC in question. I have to wait until the person who is experiencing the problem is here again ;). We have a workaround, which is to use a small batch file instead (not as nice as the GUI that should display the output from the program, stil lit works). This remains a mystery.

Regards,

Arjen

[Ralf Fassel]

* Arjen Markus <arjen.m...@gmail.com>

| I checked the TMP and TEMP environment variables - they are pointing
| to the same directory and I can open files in there and write to
| them. That is no particular problem. The Tcl/Tk shell in question is a
| tclkit, patchlevel 8.6.4.
>
| (By the way, I have seen postings dating back to 1997 (!) that contain
| the same error message, so it is not a new text)
>
| The path is something like c:\users\user\tmp - so nowhere near MAX_PATH in length.

The default is (https://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/where-is-the-temporary-folder/44a039a5-45ba-48dd-84db-fd700e54fd56)

C:\Users\<username>\AppData\Local\Temp
i.e.
%USERPROFILE%\AppData\Local\Temp

so if it is not that, maybe it would be worth trying to set TMP and TEMP
explicitely to that path before starting TCL. I once had trouble with
TEMP pointing to c:\windows\temp\, with the exact symptoms you describe:
I could open/write files there, still some programs had problems opening
their temporary files in there.

| I could try building a patched version, but I have no direct access to
| the PC in question. I have to wait until the person who is
| experiencing the problem is here again ;).

It would be interesting to see which call exactly fails and the filename
in question, though with "permission denied" I bet it is CreateFile(),
since the others fail with "buffer-too-short" or "PATH too long" or
something like that.

HTH
R'

[Arjen Markus]

On Wednesday, August 14, 2019 at 9:43:31 AM UTC+2, Ralf Fassel wrote:
>
> The default is (https://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/where-is-the-temporary-folder/44a039a5-45ba-48dd-84db-fd700e54fd56)
>
> C:\Users\<username>\AppData\Local\Temp
> i.e.
> %USERPROFILE%\AppData\Local\Temp
>
> so if it is not that, maybe it would be worth trying to set TMP and TEMP
> explicitely to that path before starting TCL. I once had trouble with
> TEMP pointing to c:\windows\temp\, with the exact symptoms you describe:
> I could open/write files there, still some programs had problems opening
> their temporary files in there.
>

I may have misremembered the exact path ... like I said, I have no direct access to the machine.

> | I could try building a patched version, but I have no direct access to
> | the PC in question. I have to wait until the person who is
> | experiencing the problem is here again ;).
>
> It would be interesting to see which call exactly fails and the filename
> in question, though with "permission denied" I bet it is CreateFile(),
> since the others fail with "buffer-too-short" or "PATH too long" or
> something like that.
>

Yes, indeed. The message would possibly be more useful if it included at least the path name that was failing. (I mentioned that it happened with non-existing programs as well. Could be a clue :))

Regards,

Arjen

[Andreas Leitgeb]

Arjen Markus <arjen.m...@gmail.com> wrote:
>> | I could try building a patched version, but I have no direct access to
>> | the PC in question. I have to wait until the person who is
>> | experiencing the problem is here again ;).

Is it possible to just add some explicit stderr-redirection
to $argv ? (If that "fixes" it, the focus on the temp file
gets much stronger) -- unless of course you need to deal with
errors on stderr.

Something else I gathered from overreading this thread:
You put the program call into a batch file (.bat or .cmd?)
If even a non-existant program causes the same error, then
why does a shell-script not-cause it? strange...

[Arjen Markus]

On Monday, August 26, 2019 at 1:55:46 PM UTC+2, Andreas Leitgeb wrote:

Hm, that might be an idea - that would mean that the creation of such a temporary file would be under our own control. The typical error messages appear only at the end of the program (because they are issued when the program decides it cannot continue), so retrieving and displaying them should not be a big issue. I will look into it, thanks for the idea.

Regards,

Arjen

[Andreas Leitgeb]

Arjen Markus <arjen.m...@gmail.com> wrote:
> On Monday, August 26, 2019 at 1:55:46 PM UTC+2, Andreas Leitgeb wrote:
>> Is it possible to just add some explicit stderr-redirection
>> to $argv ? (If that "fixes" it, the focus on the temp file
>> gets much stronger) -- unless of course you need to deal with
>> errors on stderr.

> Hm, that might be an idea - that would mean that the creation of such a
> temporary file would be under our own control. The typical error messages
> appear only at the end of the program (because they are issued when the
> program decides it cannot continue), so retrieving and displaying them
> should not be a big issue. I will look into it, thanks for the idea.

Sorry for spelling out a triviality, but if you redirect stderr to a
file, then this might lead to [close $pipe] no longer detecting error
conditions - in particular those that only manifested in stderr output
but no childstatus/exitcode. You'll have to check size of stderr-file
yourself.

[Arjen Markus]

On Tuesday, August 27, 2019 at 11:54:06 AM UTC+2, Andreas Leitgeb wrote:

I had the opportunity to reinstall the software in question on the laptop in question. There were mysterious messages during this procedure (which we could happily ignore) and the software simply works. Without any changes along the lines suggested. I have no clue as to what went wrong in the first place, but I am glad it is now solved.

(Of course, I will need to keep this in mind, should the same mystery surface again)

Regards,

Arjen