Nobody else is doing enough upload traffic to be bothered by this? I don't think the fix is that difficult, but would want some discussion on where that fix should be. Kind of think HTTP::Body should be cleaning up after itself, but that would be a significant change from how it currently works.
On Wed, Jan 13, 2010 at 6:53 AM, Bill Moseley <mose...@hank.org> wrote: > HTTP::Body::Multipart creates temporary files for uploads. The temp files > are created with File::Temp( UNLINK => 1 ). > > Catalyst then deletes these temp files in $c->finalize. The problem is > that an exception can happen and then the temp files are not deleted. > Happens quite often, it turns out. I seem to always see this in the logs > at the time of the orphaned temp file: > > Caught exception in engine "Apache2::RequestIO::read: (104) Connection > reset by peer > > Aborting an upload isn't that unusual. > > I can set temp directory for these uploads and use cron to clean them out, > but I wonder if they could not be cleaned up better automatically. > > For example, unlink in DESTROY when the request object goes out of scope. > Or perhaps better, don't have HTTP::Body set UNLINK => 1 by default and when > the upload object finally goes out of scope File::Temp will remove the temp > file. HTTP::Body explicitly removes the File::Temp object from the upload > part, but I'm not sure why it needs to do that. Why not leave the > File::Temp object in the upload part object then let it go out of scope at > the end of the request. > > Where should this be addressed? In Catalyst or in HTTP::Body? > > -- > Bill Moseley > mose...@hank.org > -- Bill Moseley mose...@hank.org
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
