POV-Ray

The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.

Tasklist

FS#206 - "Cannot open file" error when text output files specified in INI

Attached to Project: POV-Ray
Opened by Thomas B. (TPReal) - Friday, 27 May 2011, 21:02 GMT
Last edited by William F Pokorny (wfpokorny) - Monday, 21 November 2016, 14:00 GMT
Task Type Possible Bug
Category Frontend → Other
Status Tracked on GitHub
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 RC3
Due in Version 3.71 release
Due Date Undecided
Percent Complete 50%
Votes 1
Private No

Details

I created an INI file which specifies the Input_File_Name, Output_File_Name, and also the Render_File and the remaining four text outputs as double-quoted absolute paths on my disk. When I run the render, I get the following output:

Preset INI file is ‘C:\USERS\TPREAL\DOCUMENTS\POV-RAY\V3.7\INI\QUICKRES.INI’, section is ‘[512×384, No AA]’.
Preset source file is ‘D:\Ruby\POV-Rb\ini\20110521_004037_Noix.ini’.
Rendering with 2 threads.
-
Cannot open file.
Render failed
-
CPU time used: kernel 0.06 seconds, user 0.02 seconds, total 0.08 seconds.
Elapsed time 0.52 seconds.

And the render does not start. The five text output files are not even created, and where the output image should be, there is a file with extension pov-state. The render works as it should only when I remove all five lines defining the five text output files. The paths I specify for the files are correct (paths exist and files do not, no white-spaces or anything), read/write restrictions are disabled in POV-Ray. This used to work in 3.6 and does not work now in 3.7 RC3. The error happens no matter if I run the render using GUI or command line.

(Also please note that the error message is really not useful here, it does not say which file it failed to open, and not even if it was an attempt to open for read or for write.)

I’d be really glad if you could correct this as it’s a critical functionality for me. I’m generating the POV-Ray code automatically and I need to parse the text output automatically to return the status to the generator.

This task depends upon

Comment by Grimbert Jérôme (Le_Forgeron) - Saturday, 28 May 2011, 16:22 GMT

What is the state of the IO-Restrictions ?
(or turned otherwise: can I see the pathname for the intended text output ?)

If you use a subdirectory from the scene directory, it is not allowed in 3.7 by default with the io-restriction.

Comment by Thomas B. (TPReal) - Saturday, 28 May 2011, 20:01 GMT

In the Options, Script I/O Restrictions: No Restrictions selected, Permit Read/Write in Current Directory unchecked, Disable Starting Other Programs unchecked. Changing these settings does not seem to change anything.

My INI file after isolating the problem is exactly this now:

Input_File_Name="D:\Ruby\POV-Rb\pov\20110521_004037_Noix.pov"
Render_File="C:\Noix_render.log"

Even if I set the Render_File to a file in the same directory as the pov file, it fails with the same error. But when I comment out the second line, it works.

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 30 May 2011, 05:57 GMT

I tried it on Windows this morning: looks like the value of Render_File is better as a filename, NOT a pathname. i.e. no change of directory is ok
( "Render_File=foo.txt" is ok, "Render_File=C:/foo.txt" or "Render_File=C:\foo.txt" is not)

Well, you can have relative directory: "Render_File=../foo.txt" is ok too.

Think relative instead of absolute path ?

Comment by Thomas B. (TPReal) - Thursday, 02 June 2011, 09:34 GMT

OK, relaive path works fine, thanks for helping me with that. But still I think this is a bug. First - why couldn't absolute paths work? And second - the error message is really useless.

Comment by Christoph Lipka (clipka) - Thursday, 02 June 2011, 10:24 GMT

I just gave this a quick test: In the case of Render_File, POV-Ray apparently fails to recognize absolute path names with drive letters, resulting in file names such as "D:\Ruby\POV-Rb\pov\C:\Noix_render.log". (The error message in case of active IO restrictions is much more helpful in this respect.)

I'll have a closer look at what's going wrong in there, and also whether printing the filename can easily be added.

Comment by Christoph Lipka (clipka) - Thursday, 02 June 2011, 11:28 GMT

Aaah, yes... got some light here; what the Docs fail to tell us: The Render_File name is expected to be a filename only, without any path. That it happens to work with relative path names is just pure luck.

Comment by Thomas B. (TPReal) - Thursday, 02 June 2011, 11:44 GMT

Oh no. But why? I really like it more to have separate directories for log files and scenes. It is a regression - it used to work in 3.6. Couldn't this be restored?

Comment by Jim Holsenback (jholsenback) - Thursday, 02 June 2011, 11:45 GMT

as far as the docs Render_File is only mentioned:
http://wiki.povray.org/content/Documentation:Reference_Section_1.3#Directing_Text_Streams_to_Files

does the expectation that file name only without path apply to any others in this section, or is it just specific to Render_File?

Comment by Christoph Lipka (clipka) - Thursday, 02 June 2011, 11:56 GMT

Same goes for all the text stream files, i.e. Debug_File, Fatal_File, Render_File, Statistic_File, Warning_File, and of course All_File. INI file and command line options are probably both affected.

Not sure whether we want to change the docs or the code though.

Comment by Christoph Lipka (clipka) - Thursday, 02 June 2011, 12:32 GMT

Change #5446 will improve error messages. Further action is still to be decided.

Comment by Thorsten Fröhlich (thorsten) - Thursday, 25 August 2011, 19:30 GMT

I would suggest to leave this as is for 3.7.0 and see if we can allow everything (full and relative path) in 3.7.1.

Comment by Chris Cason (chrisc) - Friday, 26 August 2011, 02:35 GMT

Agreed we should fix this in 3.7.1.

Comment by William F Pokorny (wfpokorny) - Monday, 21 November 2016, 14:00 GMT
  • Field changed: Status (Investigating → Tracked on GitHub)

Now tracked on github as issue #155.

Loading...