[Catalyst] Re: Not cleaning up temporary files / HTTP::Body

[Bill Moseley]

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 <moseley at hank.org> wrote:

> HTTP::Body::Multipart creates temporary files for uploads.  The temp files
> are created with File::Temp( UNLINK =3D> 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 =3D> 1 by default and=
 when
> the upload object finally goes out of scope File::Temp will remove the te=
mp
> 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
> moseley at hank.org
>



-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100114/4ea9d=
9aa/attachment.htm