This seems like a rather obtuse restriction.
I'm running PovClipse with povray 3.7 and PovClipse generates a .ini 
file with:

Input_File_Name="C:\home\dick\workspace\runtime-EclipseApplication\b\scene\test.pov"
Output_File_Name="c:\tmp\test.png"
Debug_File="C:\home\dick\workspace\runtime-EclipseApplication\b\.metadata\povray_console_debug.txt"

Everything in .metadata is magic invisible foo. i.e. the povray streams 
get swallowed up by the gui.  But I don't want it to swallow up the 
output .png file. ;)

I'm not sure what to do about this.

-- 
dik

Post a reply to this message

Am 22.03.2016 um 18:22 schrieb dick balaska:
> This seems like a rather obtuse restriction.

Consider rendering a scene that you got from some other user, complete
with an associated .ini file.

Do you really want to have to check that the .ini file doesn't happen to
include

    Debug_File="C:\a\file\that\is\very\important\to\you.txt"

in case the other person happens to have the habit of redirecting the
debug output there (not to mention the possibility of malicious intent)?

So it's not /totally/ bananas.

Post a reply to this message

Le 22/03/2016 18:22, dick balaska a écrit :
> This seems like a rather obtuse restriction.
> I'm running PovClipse with povray 3.7 and PovClipse generates a .ini file with:
> 
> Input_File_Name="C:\home\dick\workspace\runtime-EclipseApplication\b\scene\test.pov"
> Output_File_Name="c:\tmp\test.png"
>
Debug_File="C:\home\dick\workspace\runtime-EclipseApplication\b\.metadata\povray_console_debug.txt"
> 
> Everything in .metadata is magic invisible foo. i.e. the povray streams get
swallowed up by the gui.  But I don't want it to swallow up the output .png file. ;)
> 
> I'm not sure what to do about this.
> 

It's a choice made in source/frontend/renderfrontend.cpp, circa line 286. with
variation on the operating system:
The path must not have a volume and must not have any directory component.

unix: non empty volume for path starting with "/", directory components are separated
with ulterior "/".
windows: non empty volume are either "<letter>:" or start with "\\".
Drive letter must be absolute path (so third char is "/") and relative \\ path are not
supported.

With current choice, one possibility on unix would be to create a symlink in picture
directory to have the text file somewhere else (create a dangling link, then render):

Input_File_Name="mesh2sdl.pov"
Output_File_Name="zoo/mesh2sdl.png"
Debug_File="debug.txt"

$ ls -lR
.:
total 232
-rw-rw-r-- 1 jerome jerome     90 mars  22 18:52 mesh2sdl.ini
-rw-rw-r-- 1 jerome jerome  97256 mars  19 05:30 mesh2sdl.png
-rw-r--r-- 1 jerome jerome   1554 mars  19 05:30 mesh2sdl.pov
-rw-rw-r-- 1 jerome jerome 122098 mars  19 05:14 meshsdl.png
-rw-r--r-- 1 jerome jerome   1782 mars  19 05:14 meshsdl.pov
drwxrwxr-x 3 jerome jerome   4096 mars  22 18:53 zoo

./zoo:
total 28
lrwxrwxrwx 1 jerome jerome    16 mars  22 18:53 debug.txt -> foobar/debug.txt
drwxrwxr-x 2 jerome jerome  4096 mars  22 18:53 foobar
-rw-rw-r-- 1 jerome jerome 24434 mars  22 18:53 mesh2sdl.png

./zoo/foobar:
total 0
-rw-rw-r-- 1 jerome jerome 0 mars  22 18:53 debug.txt

So... kind of not a big problem... for unix.

The purpose of the code in renderfrontend is to avoid messing with filesystem (against
offensive scene):
if you allow a scene to write in c:\Windows\whatever.dll, you can kill the operating
system.
(for default installation, in English; I know some German user which use a different
directory)

I do not know if you can perform the same link trick on Windows... not available here
for test.

If you cannot, either you find a way for eclipse to look at the rendering directory,
or you will need your own compilation with a patch to avoid such check (and that's
dangerous).

Post a reply to this message

Am 2016-03-22 14:00, also sprach clipka:
 >
 > So it's not /totally/ bananas.

Yes, that makes total sense. (Way more sense than hardcoding 80 as the 
line width in the *constructor* of a stream class... but I digress)


Am 2016-03-22 14:05, also sprach Le_Forgeron:
> If you cannot, either you find a way for eclipse to look at the rendering directory,

yes, I think what I'll do is
$ cd output_dir
$ launch_povray

and then make eclipse deal with the streams in that directory.

 > or you will need your own compilation with a patch to avoid such 
check (and that's dangerous).

While I do use my own compilation, I don't want to remove this feature. 
  I'm sold on its usefulness.

And I'm totally uninterested in creating something that would have no 
chance of ever being accepted in povray proper.

-- 
dik

Post a reply to this message

Am 2016-03-22 14:05, also sprach Le_Forgeron:
> or you will need your own compilation with a patch to avoid such check (and that's
dangerous).

My whole renderfarm ( http://www.buckosoft.com/bsac/ ) is designed to be 
public. My thought was I would share my servers with someone else while 
I get to use their box as well.

But I never opened it up because it would be a week before someone tried 
to take down my boxes "just to see what would happen". And I don't want 
to deal with that.

(The other thing I foresee is someone creating a high priority 10 month 
job and firing that off on every server "just to see which one finishes 
first")


-- 
dik

Post a reply to this message

On 22.03.2016 19:00, clipka wrote:

> So it's not /totally/ bananas.

No, but maybe it should be tied to "Script I/O restrictions".
I just tried and when I disable that I can write the output image
in any directory (and overwrite a txt file next to it). Allowing
location for stream would seem to be ok with same level of trust.

Post a reply to this message