[Bug]: Images left in a temp folder C:\Users\username\AppData\Local\Temp

[4lt3r3go]

Is there an existing issue for this?

• I have searched the existing issues and checked the recent builds/commits

What happened?

founded 1,6 GB of spare images created by the UI in the folder C:\Users\username\AppData\Local\Temp

Steps to reproduce the problem

i hope to be helpfull.

What should have happened?

.

Commit where the problem happens

No response

What platforms do you use to access UI ?

Windows

What browsers do you use to access the UI ?

Brave

Command Line Arguments

No response

Additional information, context and logs

No response

[MegaScience]

To expand on this: It appears every time this is opened, a new temp folder is created, which isn't cleared. After reading this thread, I used a space manager on my temp folder and found all the offending folders within.

[rasamaya]

I experience this too, just deleted thousands of images

[samuel-reyes]

Also experienced this. I just freed up 30 gigs by deleting left over SD images...
Genuine question: Why do we need the temp folder? Can we not just use the images in the folder they were generated in instead for the preview images?

[C43H66N12O12S2]

Gradio creates these files, even when using the "bytes" type. Not sure if intended or not on Gradio's part, and I couldn't find a way to disable this behaviour.

[ReiFan49]

Tempfile issue came from gradio-app/gradio#2265 commit. This repo only managed to patch what gradio had done to our temporary storage by not clearing it, and also exposing security issues to it.

I tested randomly to access the SD Webui content of my friend's server by asking specific dir, and I managed to be able to steal his files by using this recent patch. The file= support been there since months but the recent base64 change is from gradio itself as what I've been looking again. Kinda dangerous security issue they had exposed from 3.5 update.

Need a restricted access to the file= parameter, and it's outside of this repository scope sadly. All of this are handled by gradio instantly.

[stefnotch]

Would it make sense to open an issue in the upstream Gradio repository about this? After all, that's a genuine issue, especially on Windows systems where the temp directory doesn't automatically get cleared. It's also an issue on long running servers, as the temp directory on Linux gets cleared when one restarts the machine or after quite a few days.

As far as I can tell, they're using the https://docs.python.org/3/library/tempfile.html library, (e.g. here ), but not properly cleaning up those files.

[papuSpartan]

Worst case I think we could try having a parallel process launched that starts cleaning this area when the UI starts.

[baloneysammich]

Don't know if this is still necessary, but putting something like

os.environ["TEMP"] = os.environ["TMP"] = "[drive]:/path/to/dir"

in launch.py seems to completely override the system-level user variables.

I redirected to a ramdisk, but if nothing else it should make it easier to keep things clean.

[anastasiuspernat]

os.environ["TEMP"] = os.environ["TMP"] = "[drive]:/path/to/dir"

Great find! Just realized I had 10gb of files in my temp folder and they multiply.
I now chain commands in the following way (Windows Terminal):

rm "[my-temp-path]*" -r; $env:COMMANDLINE_ARGS="[webui-args]"; $env:TEMP="[my-temp-path]"; $env:TMP="[my-temp-path]"; .\webui.bat;

So it cleans up temp folder every time the webui starts.