Skip Menu |

This queue is for tickets about the File-Slurp CPAN distribution.

Report information
The Basics
Id: 63318
Status: resolved
Priority: 0/
Queue: File-Slurp

Owner: Nobody in particular
Requestors: user42 [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

From gg [...] Wed Nov 24 19: 41:13 2010
MIME-Version: 1.0
X-Spam-Status: No, score=-6.9 tagged_above=-99.9 required=10 tests=[AWL=0.000, BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
X-Spam-Flag: NO
content-type: text/plain; charset="utf-8"
Message-ID: <87mxoyqlpj.fsf [...] blah.blah>
X-Virus-Scanned: Debian amavisd-new at
X-Spam-Score: -6.9
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5182B2411A0 for <cpan-bug+File-Slurp [...]>; Wed, 24 Nov 2010 19:41:13 -0500 (EST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cuVIuAr8tEIf for <cpan-bug+File-Slurp [...]>; Wed, 24 Nov 2010 19:41:11 -0500 (EST)
Received: from ( []) by (Postfix) with SMTP id 4F2F1241183 for <bug-File-Slurp [...]>; Wed, 24 Nov 2010 19:41:10 -0500 (EST)
Received: (qmail 9601 invoked by uid 103); 25 Nov 2010 00:41:10 -0000
Received: from ( by with QMQP; 25 Nov 2010 00:41:10 -0000
Received: from (HELO ( by (qpsmtpd/0.80) with ESMTP; Wed, 24 Nov 2010 16:41:07 -0800
Received: from ( []) by (Postfix) with ESMTP id 1D1102A7C2E for <bug-File-Slurp [...]>; Thu, 25 Nov 2010 11:41:02 +1100 (EST)
Received: from blah.blah (unknown []) by (Postfix) with ESMTP id 848728C05 for <bug-File-Slurp [...]>; Thu, 25 Nov 2010 11:41:00 +1100 (EST)
Received: from gg by blah.blah with local (Exim 4.72) (envelope-from <gg [...]>) id 1PLPtQ-0003Pw-S6 for bug-File-Slurp [...]; Thu, 25 Nov 2010 11:40:56 +1100
Delivered-To: cpan-bug+File-Slurp [...]
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux)
Subject: "atomic" temp file on write error
Return-Path: <gg [...]>
X-RT-Mail-Extension: file-slurp
X-Original-To: cpan-bug+File-Slurp [...]
Date: Thu, 25 Nov 2010 11:40:56 +1100
To: bug-File-Slurp [...]
From: Kevin Ryde <user42 [...]>
X-RT-Original-Encoding: us-ascii
Content-Length: 527
Download (untitled) / with headers
text/plain 527b
Nosing around File::Slurp 9999.13 I wondered if write_file() "atomic" mode may leave behind its temp file if it encounters a syswrite() error. The pod notes it may be left behind on various crashes or interrupts but I think it could helpfully be cleaned up for an error detected within write_file(). I suppose one possibility might be letting File::Temp or a similar scope-guarded thingie delete the file if not successfully reaching the rename stage. That might catch anything that at least goes through the normal exit().
MIME-Version: 1.0
In-Reply-To: <87mxoyqlpj.fsf [...] blah.blah>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <87mxoyqlpj.fsf [...] blah.blah>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-18806-1306128457-633.63318-0-0 [...]>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 139
Download (untitled) / with headers
text/plain 139b
the rename call is now error checked (and tested in t/error.t). all you need to do is wrap the write_file call in eval to trap any errors.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to