Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 04 Jan 2009 20:43:23 +0000
From:      Kris Kennaway <kris@FreeBSD.org>
To:        obrien@freebsd.org
Cc:        "Carlos A. M. dos Santos" <unixmania@gmail.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r186337 - head/usr.sbin/burncd
Message-ID:  <49611F6B.10802@FreeBSD.org>
In-Reply-To: <20081223182314.GC25145@dragon.NUXI.org>
References:  <200812192020.mBJKKEIo081792@svn.freebsd.org> <e71790db0812210415s34231791w180e33d358142b4f@mail.gmail.com> <20081223182314.GC25145@dragon.NUXI.org>

next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien wrote:
> On Sun, Dec 21, 2008 at 10:15:21AM -0200, Carlos A. M. dos Santos wrote:
>> On Fri, Dec 19, 2008 at 6:20 PM, David E. O'Brien <obrien@freebsd.org> wrote:
>>> Author: obrien
>>> Date: Fri Dec 19 20:20:14 2008
>>> New Revision: 186337
>>> URL: http://svn.freebsd.org/changeset/base/186337
>>>
>>> Log:
>>>  burncd(8) doesn't handle signals and interrupting burncd during operation.
>>>  For example, ^C (SIGINT) may leave the drive spinning and locked.
>>>  This may also happen if you try to write a too-large image to a disc
>>>  and burncd(8) exits with an I/O error.
>>>
>>>  Add signal handling by doing a CDRIOCFLUSH ioctl to attempt to leave
>>>  burner in a sane state when burning is interrupted with SIGHUP, SIGINT,
>>>  SIGTERM, or in case an I/O error occurs during write.
>>>  Note, that blanking will still continue after interrupt but it seems to
>>>  finish correctly even after burncd(8) has quit.
>>>
>>>  Also, while I'm here bump WARNS to "6".
>>>
>>>  PR:           48730
>>>  Submitted by: Jaakko Heinonen <jh@saunalahti.fi>
>> While you are here, would you mind taking a look at bin/123693, either
>> committing the proposed patch or closing the PR if my proposition is
>> not acceptable?
> 
> Yep, I already have that patch to look at.  Note it was hell getting the
> patch - its best to not attach it when it will be base64 encoded - we
> have no easy way of extracting such encoded attachements.
>  

AFAIK, the web PR interface will detect base64-encoded attachments and 
present them for download.

Kris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49611F6B.10802>