From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8579 invoked by alias); 14 Nov 2009 16:18:42 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 27404 Received: (qmail 23804 invoked from network); 14 Nov 2009 16:18:40 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C autolearn=no version=3.2.5 Received-SPF: none (ns1.primenet.com.au: domain at debian.org does not designate permitted sender hosts) Date: Sat, 14 Nov 2009 16:18:34 +0000 From: Clint Adams To: zsh-workers@zsh.org Cc: 555957@bugs.debian.org Subject: Re: PATCH: warn on "hard" hard link failure Message-ID: <20091114161834.GA12016@scru.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) On Tue, Mar 10, 2009 at 02:18:41PM +0000, Peter Stephenson wrote: > This is reponse to Sourceforge issue 1968395: failures to create hard > links aren't gracefully handled. Failing to create a link because the > file already exists is the normal condition being handled by the locking > code; however, a failure for any other reason is presumably a hard > failure worthy of reporting. The same goes if stat() fails with > anything other than ENOENT: in both cases we give up and should say so. > > It's possible this can be improved further. Apparently this has caused someone distress because of the hard failure preventing the correction of the out-of-diskspace condition causing the history failure.