luxconsole default location for temporary files

[Omniflux]

When running luxconsole as a slave node it usually creates temporary files for the scene it is processing.

Currently it creates these files in the "current directory" - whichever directory you launch luxconsole from.

I recently added a command line option to allow specifying an alternative directory to place these files in:
-c [ --cachedir ] arg Specify the cache directory to use

I called this cachedir instead of tempdir because of work being done on bug 614 which will allow these files to be saved on the slave node between instances of running luxconsole.

This has the potential to lead to many files appearing in unexpected locations for some users. How would you feel about changing the default location to the users temp directory?

I propose using boost::filesystem::temp_directory_path() / "luxrender"

temp_directory_path() will return the users personal temp directory on windows, and on unix will check the environment variables TMPDIR, TMP, TEMP, and TEMPDIR in that order, with a fallback to /tmp.

Thus files will by default be saved in for example:
/tmp/luxrender
or
C:\Users\Omniflux\AppData\Local\Temp\luxrender

There is a downside to this on unix systems which by default use a shared temp directory; the directory and files will be owned by the first user to run luxconsole as a slave node. Other users can work around this by specifying another directory with -c, or we could use another default directory incorporating the username or userid (/tmp/luxrender-omniflux or /tmp/luxrender-1001).

A traditional method is to use the process id as part of the temporary directory name, however for this directory to function as a cache directory, the path must remain stable between instantiations.

What are your thoughts on this?

[SATtva]

There is a downside to this on unix systems which by default use a shared temp directory; the directory and files will be owned by the first user to run luxconsole as a slave node. Other users can work around this by specifying another directory with -c, or we could use another default directory incorporating the username or userid (/tmp/luxrender-omniflux or /tmp/luxrender-1001).

A traditional method is to use the process id as part of the temporary directory name, however for this directory to function as a cache directory, the path must remain stable between instantiations.

Right. I agree with [TMP]/luxrender-[username] scheme -- it's not uncommon to restart node processes, so using a PID in the cache dir name has no sense.

[cwichura]

I agree that a postfix should be used. Using username should be safe enough, though unix often uses the UID instead. I think it's six to one, half-a-dozen of the other as to which is better to use.

Another thing to consider would be making a multilevel structure, so you'd have a 'cache' directory under the luxrender directory in temp. Right now, there isn't much else to write (except maybe a PID file), but it gives you the flexibility to add other lux-related temp directories easily in the future. And to the end user, just walking the /tmp directory structure, it would make it much more clear what the directory is being used for.

If you go the multi-level structure route, then you should probably change the command-line from 'cachedir' to something like 'tempdir'. Then you could also put a 'film' subdirectory in there, where the temporary server film file would be written to when the -W option is specified.

[SATtva]

I agree that a postfix should be used. Using username should be safe enough, though unix often uses the UID instead.

You're right of course, numeric UIDs is a more correct approach.

[Lord Crc]

On Windows the temp folder for any supported version of Windows will be per-user, unless luxrender runs in the system context in which case it'll use the system temp folder.

As such on windows I think %temp%/luxrender is sufficient. The idea of using a "cache" folder below that is a good one I think.

[Lord Crc]

I thought about a way to make such a change somewhat backwards compatible.

At startup, we could see if the current working directory is the one where the executable lives (ie from args[0]), and only change the working directory to the temp folder if it is. This should allow us to preserve scripts etc which relies on the old behavior.

[cwichura]

Sounds fine, so long as it only applies when no explicit temp directory has been specified on the command line. If the user specifies a temp dir on the command line (or, I suppose, via the config file loading that I thought I saw Omni had added) then you should use it, regardless of where Lux is launched from.

Also need to make sure this works properly when Lux is launched from an .lxs file directly due to file association bindings.

[Omniflux]

I have created a patch to use boost::filesystem::temp_directory_path() / "luxrender[-euid]" / cache
where euid is the effective user id on a posix system.

Windows example: C:\Users\Omniflux\AppData\Local\Temp\luxrender\cache
Posix example: /tmp/luxrender-1000/cache

If you go the multi-level structure route, then you should probably change the command-line from 'cachedir' to something like 'tempdir'. Then you could also put a 'film' subdirectory in there, where the temporary server film file would be written to when the -W option is specified.

I have made no changes here, as yet.

I thought about a way to make such a change somewhat backwards compatible.

At startup, we could see if the current working directory is the one where the executable lives (ie from args[0]), and only change the working directory to the temp folder if it is. This should allow us to preserve scripts etc which relies on the old behavior.

I have not thought this through completely, but I am not sure this will work *consistently* because args[0] contains the name as called by the user, not an absolute path to the executable.