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>