fasthttp.SaveMultipartFile() generate tmp file without clean

[laoshanxi]

After fasthttp.SaveMultipartFile(file, filePath) for several files I found the tmp file under /tmp was not cleaned, is this designed behavior? how could I get the tmp file path for each SaveMultipartFile and remove after file received?

$ ls /tmp
multipart-1116084598  multipart-1806005773  multipart-2359895161  multipart-2868180902  multipart-3505259536  multipart-4200780900  multipart-957202837
multipart-1432350850  multipart-2089011025  multipart-2449044315  multipart-2881117185  multipart-3587317179  multipart-423553165
multipart-147667864   multipart-2165895272  multipart-2650738835  multipart-3031107618  multipart-371009225   multipart-520911278
multipart-1499565166  multipart-2181355762  multipart-2700390650  multipart-3223448677  multipart-3975570320  multipart-687744821
multipart-1576810887  multipart-2347928608  multipart-2827028297  multipart-3254124333  multipart-408984157   multipart-931328463

[erikdubbelboer]

Can you show me the rest of your handler, how you use SaveMultipartFile?

[laoshanxi]

I checked the code FileHeader.Open() will create a tmpfile which finally rename to target file: https://github.com/valyala/fasthttp/blob/master/server.go#L1051

but the rename will fail if the target path is on different logic volume, in this case, the tmp file will be stay there without clean:

		// If renaming fails we try the normal copying method.
		// Renaming could fail if the files are on different devices.
		if os.Rename(ff.Name(), path) == nil {
			return nil
		}

actually, the file save path is always not in /tmp dir, in order to workaround this, I have to adjust my code like this: https://github.com/laoshanxi/app-mesh/blob/main/src/sdk/agent/restagent.go#L237

I think A possible fix to this is after e := ff.Close() in SaveMultipartFile, call os.Remove(ff.Name()) can resolve this issue.

[erikdubbelboer]

You are right. You mind making a pull request to fix it?

[laoshanxi]

Yes, I can make a fix.