Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Jan 2009 08:48:32 -0800
From:      "David O'Brien" <obrien@FreeBSD.org>
To:        Kris Kennaway <kris@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:  <20090105164832.GF46222@dragon.NUXI.org>
In-Reply-To: <49611F6B.10802@FreeBSD.org>
References:  <200812192020.mBJKKEIo081792@svn.freebsd.org> <e71790db0812210415s34231791w180e33d358142b4f@mail.gmail.com> <20081223182314.GC25145@dragon.NUXI.org> <49611F6B.10802@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 04, 2009 at 08:43:23PM +0000, Kris Kennaway wrote:
> 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.

Everytime I tried, I wound up with a binary file being downloaded.

-- 
-- David  (obrien@FreeBSD.org)



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