Ability to customize Gradio's output folder for gr.File uploads

[space-nuko]

• I have searched to see if a similar issue already exists.

Is your feature request related to a problem? Please describe.
The ability to specify where files served by gr.File are uploaded would be very useful, right now it's always set to a temporary folder named after the hash of the file and it is not configurable

gradio/gradio/components.py

Lines 240 to 241 in 7856382

	temp_dir = self.hash_file(file_path)
	temp_dir = Path(self.DEFAULT_TEMP_DIR) / temp_dir

That would allow cleaning up the temporary files on each startup, currently there's no centralized place in the temporary folder where Gradio stashes its temporary files, they just accumulate over time

It should allow specifying a path outside the system temporary directory also. Of course the path specified should be added to temp_file_sets so it's treated as an allowed path

And filename collisions would need to be dealt with somehow. Maybe a way for the user to specify an output subdirectory/filepath to the value sent to a gr.File output. Or automatically renaming duplicate files. But the current solution of putting each file in a separate hashed folder isn't very useful, they should all be placed in one folder ideally.

One more thing I noticed, this hashing scheme also leaves behind a 0-sized temporary file in the created folder, I think it's unintentional - AUTOMATIC1111/stable-diffusion-webui#8752 (comment)

Describe the solution you'd like
Ability to set Interface.upload_path to the root folder where IOComponent.make_temp_copy_if_needed should dump files

Additional context
Specific usecase is better articulated by AUTOMATIC1111/stable-diffusion-webui#8752 (comment)

[abidlabs]

And filename collisions would need to be dealt with somehow. Maybe a way for the user to specify an output subdirectory/filepath to the value sent to a gr.File output. Or automatically renaming duplicate files. But the current solution of putting each file in a separate hashed folder isn't very useful, they should all be placed in one folder ideally.

The reason we do it like this is:

• The hash ensures that the file paths are deterministic (if the same file is processed multiple times, it gets mapped to the same path avoiding the creation of unnecessary files)
• The fact that the hash is part of the directory as opposed to the file name allows us to preserve file names of uploaded files

I don't think we'd change the above behavior, but we could certainly allow users to set a parent directory where all temporary files would be stored so:

That would allow cleaning up the temporary files on each startup, currently there's no centralized place in the temporary folder where Gradio stashes its temporary files, they just accumulate over time

It should allow specifying a path outside the system temporary directory also. Of course the path specified should be added to temp_file_sets so it's treated as an allowed path

[Cyberbeing]

I also don't see a problem with the behavior of images being added to separate hashed folders. As long as all temporary folders/files end up contained within a single folder rather than dumped into system TEMP root, cleaning should be easy. The general problem with using system temp root, is that many different types of files from other programs end up there, some of which can't or should not be deleted indiscriminately.

I'd also suggest that even with the default behavior of placing temp files in system temp, that gradio be changed to instead place them in a gradio sub-directory within that folder. That is what well behaving programs on Windows do to keep their temp files contained and easily identified by end-users, so I think it makes sense.

A step further would be adding a built-in option for gradio to automatically clean its temp sub-directory on startup, which would also make sense, since those temp files are never used again by gradio after being killed and relaunched. That alone would resolve primary issue without needing to change the temp directory to a custom location, but custom locations should still be allowed anyway in case the user's system root is low on disk space.

[Dannypeja]

I don't want to need access to /tmp/ in order for this to work as I don't have it on the current machine
Is there any way to change the directory for the tempfiles away from /tmp/gradio/ now? I've been searching for 2 hours now.
I am running on gradio==3.47.1 (latest)

[abidlabs]

Yes @Dannypeja you can set the GRADIO_TEMP_DIR environment variable to point to the absolute path where you'd like Gradio's temporary files saved.

[Moibe]

For me it would work just to know how a file is hashed, then I can search programatically in the temp folder. How the files is coded? so I can run the same process to know the name of the ffolder.