Current directory used for temporary files

Bug #678632 reported by Denilson Sá on 2007-04-02
50
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Hugin
Status tracked in Default
Default
Wishlist
Unassigned

Bug Description

I've tried to use hugin and enblend with TIF output. However, this generated two TIF files with more than 100MB, which filled up my /home partition. However, I have a few gigabytes free at another partition.

A similar issue could arise if /home was a network-mounted filesystem. Even though I would want to operate on files from that filesystem and save the final result there, those huge temporary files should be stored elsewhere (/tmp or any user-defined place).

My suggestion: allow the user to specify an alternate temporary directory.

Denilson Sá (denilsonsa) wrote :

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.

kflash (kflash) wrote :

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!

Denilson Sá (denilsonsa) wrote :

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

Bruno Postle (brunopostle) wrote :

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)

kflash (kflash) wrote :

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

Lukas Jirkovsky (l-jirkovsky) wrote :

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.

rew (r-e-wolff) wrote :

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.

tags: added: tmpdir
rew (r-e-wolff) on 2010-12-03
tags: added: ignored linux
Yuv (yuv) wrote :

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

rew (r-e-wolff) wrote :

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

Yuv (yuv) wrote :

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?

summary: - Windows uses current directory for temporary files
+ Current directory used for temporary files
Bruno Postle (brunopostle) wrote :

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.

rew (r-e-wolff) wrote :

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.

Yuv (yuv) wrote :

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.

Florian Demmer (fdemmer) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers