Current directory used for temporary files

Logged In: YES
user_id=1140109
Originator: YES

Sorry, looks like this is already implemented in Preferences.

At least, it should have a warning or some error message whenever the disk/partition becomes full.

Please reopen this ticket.
The preferences settings are not working as expected. The Temp-Dir is not the one of the OS if left empty but the source dir.
This request would really improve the work for images stored remotely or on USB drives!

I would reopen it, but it seems I can't. And this sourceforge interface is not good...

Changing this to a bug report, the Preferences being ignored is a known bug, but Hugin should use the system default temp folder.

Which OS do you see the working directory being used as the temp directory? (on Linux /tmp is used and I would expect the same on OS X)

I'm using Windows XP and an "inofficial build" of Hugin with version number "Version 2009.1.0.4240 Ad Huikeshoven"

IIRC correctly this should have been fixed by commit #3635 in svn quite some time ago. It might be possible that some of the external tools doesn't care about temporary dir settings.

I just tested this. Setting tmp dir in preferences to "/tmp" will still dump the nona-output (which is one of the steps that could produce lots of very big files) in the current directory.

So does this affect Windows only? or also Linux? and OSX?

I tested this on Linux. I suspect that OSX does the same.

Thanks for the feedback, Roger.

I think the files concerned are the remapped images only?

If this is the case, then it is a matter of defining what file is temporary and what not. If I check any of the boxes in the Remapped Images section of the Stitcher tab then these are not temporary files and the current behavior is correct. But if those checkboxes are unchecked then the images remapped by nona are temporary and the current application behavior is incorrect.

Can you confirm?

Just clarifying: the remapped intermediate images are always written to the working directory regardless of whether they are 'temporary' (i.e. even when Hugin deletes them afterwards).

This is how Hugin has worked since the Makefile stitching system was implemented, but there are good reasons to change it: The temp directory could be on a larger partition, or it could be on a faster partition such a ramdisk.

Fixing this would require creating a secure folder in the temp directory and writing any intermediate files that the user hasn't asked to keep in this folder. i.e. if the user asks to keep all temporary files then the behaviour would be the same as currently.

Bruno, exactly.

Just to clarify, I'm not the original reporter, but I can understand the issue. Also, a friend ran into this, as she "works" in the NFS-mounted directory that has backups etc etc, but there is no reason to send the "temporary" nona remapped images over the network (back and forth).

Anyway, yes, the temporary files stop being temporary when you indicate you want to keep them.
And by that time, the storage space in the current directory needs to be there anyway, if they don't fit, there is no way to make them fit.

thanks for the clarifications. now we know that this is a feature request (i.e. the current behavior is correct and the new behavior is a desirable feature) and we have an idea of what files are concerned and what needs to be done to implement the new behavior. Wishlist.

is there a workaround to have hugin put the remapped images somewhere else? a fixed directory independent from where the project is saved?