MapGuide does not clean up temporary files

[ksgeograf]

When running MapGuide, there seems to be quite a lot of temporary files left in the C:\windows\temp folder.

All the files have the format "7c116e96-0000-1000-8000-005056c00008". Where the 1. and second component are either "0000-1000" or "ffff-ffff".

On my system I have 77658 of those, so clearly these get left behind during normal operation, and not just on service restarts.

[zspitzer]

Looking into the file, this might be fusion related

[ksgeograf]

I have tried to open some of the files, and it appears to be everything I have ever sent to the server (probably everything thorugh the Web interface?). I have found runtime layer data, mapdefinitions and even an MGP package.

[tomfukushima]

Hi Kenneth, So to reproduce this, we only have to start up Maestro, connect to the server, and create a resource such as a feature source, layer definition, map definitiion etc.? Thanks, Tom

[zspitzer]

The are also a lot of IDFxxx.tmp files being created there which are open by the mgserver process. These files are usally 34mb also often extremely fragmented, ie 4k fragments

[ksgeograf]

I just experimented, and this problem is reproduceable:

1. Delete all files from C:\Windows\temp
2. Open Maestro
3. Open a resource (eg. Map).
4. Save the resource

A new file appears in C:\windows\temp

To make sure the problem isn't Maestro, I just tried this with Studio, and it has the same behavior. I tried monitoring the mgserver.exe process, and it does not appear to have a handle to any of the created files, so the problem is most likely in the web tier.

I have none of the IDFxxx.tmp files in C:\Windows\temp.

[waltweltonlair]

The problem occurs in the web tier in two places: MapAgentCommon::PopulateData and CgiPostParser::Parse. Whenever we get a multipart/form-data post request we scan for a "filename=" parameter. If found we save the content to a temporary file, and use the temporary file name as the content's value. Then when the code contacts the server with the request it reloads the data from the temporary file. But..., once everything is done these temporary files are never deleted.

There's a TODO comment in MapAgentCommon::PopulateData and CgiPostParser::Parse about changing the infrastructure so that the content's data can be directly passed in, rather than using the temporary file. Making this change is the way to fix this.

I must say it's very annoying when all these temp files get left behind.

[trevorwekel]

Temporary files of the form '{mgsessionid}' are created from HTTP SetResource, SetResourceContent, SetResourceData, CreateRepository, and ApplyResourcePackage. Temporary files of the from 'sess_{mgsessionid}' are PHP sessions created by the fusion viewer. And temporary files of the form 'sess_{random string)' are PHP sessions generated from the site administrator.

[waltweltonlair]

Partially fixed with trunk stream submission ​https://trac.osgeo.org/mapguide/changeset/3708.

Temporary files of the form '{mgsessionid}' will no longer get left behind as part of HTTP SetResource, SetResourceData, UpdateRepository, CreateRepository, and ApplyResourcePackage requests.

[waltweltonlair]

The PHP sessions are created when using fusion or the site administrator. PHP, however, manages their lifetime. So when these get left behind it's something to do with PHP.

[waltweltonlair]

I think this has been addressed satisfactorily.

[waltweltonlair]

Additional fix with trunk submission ​https://trac.osgeo.org/mapguide/changeset/3711.