Debian Bug report logs - #262678
cdrecord: Please use O_EXCL.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

To: submit@bugs.debian.org

Subject: Prevents recording with a CDR drive

Date: Sun, 01 Aug 2004 13:51:50 GMT

Package: hal
Version: 0.2.95-4
Severity: important

I can't record with my IDE CDR at 4x with linux-2.6.7 and Debian
unstable current.

With hald running there's a buffer underrun everytime I try.
When I kill hald cdrecord works perfectly.

Message #10 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Martin Waitz <tali@admingilde.org>

To: ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>, 262678@bugs.debian.org

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Mon, 2 Aug 2004 11:49:10 +0200

[Message part 1 (text/plain, inline)]

hi :)

On Sun, Aug 01, 2004 at 01:51:50PM +0000, ROBERTOJIMENOCA wrote:
> With hald running there's a buffer underrun everytime I try.

Is this buffer underrun always happening at the same time?
Is it happening at the beginning/end of CD burning or is it random?
Are you using any applications that use hal (hal-device-manager/g-v-m)?

> When I kill hald cdrecord works perfectly.

hmm, perhaps media polling confused your CD recorder?


I don't have a CD recorder myself.
Everybody: who can confirm this bug?

-- 
Martin Waitz

[Message part 2 (application/pgp-signature, inline)]

Message #15 received at 262678@bugs.debian.org (full text, mbox, reply):

From: ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

To: 262678@bugs.debian.org

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Mon, 02 Aug 2004 11:13:33 GMT

Martin Waitz wrote:
> On Sun, Aug 01, 2004 at 01:51:50PM +0000, ROBERTOJIMENOCA wrote:
> > With hald running there's a buffer underrun everytime I try.
> 
> Is this buffer underrun always happening at the same time?

Yes, at the start of the recording session.

> Is it happening at the beginning/end of CD burning or is it random?

Always at the start of the recording session.

> Are you using any applications that use hal (hal-device-manager/g-v-m)?

Probably gnome/nautilus-cd-burner is using hal but don't know the exact app.

> > When I kill hald cdrecord works perfectly.
> 
> hmm, perhaps media polling confused your CD recorder?

Probably.

Message #20 received at 262678@bugs.debian.org (full text, mbox, reply):

From: sjoerd@spring.luon.net (Sjoerd Simons)

To: Martin Waitz <tali@admingilde.org>, 262678@bugs.debian.org

Cc: ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Mon, 2 Aug 2004 18:04:57 +0200

On Mon, Aug 02, 2004 at 11:49:10AM +0200, Martin Waitz wrote:
> hi :)
> 
> On Sun, Aug 01, 2004 at 01:51:50PM +0000, ROBERTOJIMENOCA wrote:
> > With hald running there's a buffer underrun everytime I try.
> 
> Is this buffer underrun always happening at the same time?
> Is it happening at the beginning/end of CD burning or is it random?
> Are you using any applications that use hal (hal-device-manager/g-v-m)?
> 
> > When I kill hald cdrecord works perfectly.
> 
> hmm, perhaps media polling confused your CD recorder?

This is why hald opens the cdrom devices with O_EXCL. From the hal changelog:

   * hald/linux/block_class_device.c:
   (detect_media): use O_EXCL for optical drive media detection, much
   safer since O_EXCL is actually in mainline. Removes possible burning
   problems (that is, if only cdrecord open(2)'s the device using O_EXCL;
   bug filed against fedora-devel, hopefully it will bubble upstream)

I don't know if debian's cdrecord package uses O_EXCL, probably not. So this
bug should probably reassigned.  

  Sjoerd
-- 
"Yeah, but you're taking the universe out of context."

Message #25 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Sjoerd Simons <sjoerd@spring.luon.net>

To: Martin Waitz <tali@admingilde.org>, 262678@bugs.debian.org

Cc: ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>, control@bugs.debian.org

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Mon, 2 Aug 2004 20:58:40 +0200

reassign 262678 cdrecord
thanks

On Mon, Aug 02, 2004 at 06:04:57PM +0200, Sjoerd Simons wrote:
> On Mon, Aug 02, 2004 at 11:49:10AM +0200, Martin Waitz wrote:
> > hi :)
> > 
> > On Sun, Aug 01, 2004 at 01:51:50PM +0000, ROBERTOJIMENOCA wrote:
> > > With hald running there's a buffer underrun everytime I try.
> > 
> > Is this buffer underrun always happening at the same time?
> > Is it happening at the beginning/end of CD burning or is it random?
> > Are you using any applications that use hal (hal-device-manager/g-v-m)?
> > 
> > > When I kill hald cdrecord works perfectly.
> > 
> > hmm, perhaps media polling confused your CD recorder?
> 
> This is why hald opens the cdrom devices with O_EXCL. From the hal changelog:
> 
>    * hald/linux/block_class_device.c:
>    (detect_media): use O_EXCL for optical drive media detection, much
>    safer since O_EXCL is actually in mainline. Removes possible burning
>    problems (that is, if only cdrecord open(2)'s the device using O_EXCL;
>    bug filed against fedora-devel, hopefully it will bubble upstream)
> 
> I don't know if debian's cdrecord package uses O_EXCL, probably not. So this
> bug should probably reassigned.  

Just checked. Debians cdrecord indeed doesn't use O_EXCL. So i'm reassigning
this bug. A patch can be found on
http://people.mandrakesoft.com/~warly/files/cdrtools/

It has a small but trivial to fix rejection on the current cdrtools debian
package. 

  Sjoerd
-- 
Don't stop to stomp ants when the elephants are stampeding.

Message #32 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Joerg Schilling <schilling@fokus.fraunhofer.de>

To: 262678@bugs.debian.org, ROBERTOJIMENOCA@terra.es

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Tue, 10 Aug 2004 17:06:36 +0200 (CEST)

Send a bug report to the autors of you volmgt software.

A volmgt SW that periodically (e.g. every 3 seconds) polls the drive with a
Test Unit Ready and does not try to mount a device that does not have a 
readable medium inserted (e.g. Solaris) does not disturb the writing process.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Message #37 received at 262678@bugs.debian.org (full text, mbox, reply):

From: ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

To: 262678@bugs.debian.org

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Thu, 12 Aug 2004 12:21:15 GMT

Joerg Schilling wrote:
> Send a bug report to the authors of you volmgt software.
> 
> A volmgt SW that periodically (e.g. every 3 seconds) polls the drive with a
> Test Unit Ready and does not try to mount a device that does not have a 
> readable medium inserted (e.g. Solaris) does not disturb the writing process.

Please don't post to the bugtracker if you are not going to propose
solutions.

The bug report says the problem is in cdrecord for not using O_EXCL.
Why that works in Solaris? Does Solaris have something similar to hal?

Message #42 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: Sjoerd Simons <sjoerd@spring.luon.net>

Cc: Martin Waitz <tali@admingilde.org>, 262678@bugs.debian.org, ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Thu, 9 Sep 2004 10:39:26 +0200

reassign 262678 hald cdrecord
thanks
On 2004-08-02 Sjoerd Simons <sjoerd@spring.luon.net> wrote:
> reassign 262678 cdrecord
> thanks

> On Mon, Aug 02, 2004 at 06:04:57PM +0200, Sjoerd Simons wrote:
> > On Mon, Aug 02, 2004 at 11:49:10AM +0200, Martin Waitz wrote:
> > > On Sun, Aug 01, 2004 at 01:51:50PM +0000, ROBERTOJIMENOCA wrote:
> > > > With hald running there's a buffer underrun everytime I try.
[...]
> > > > When I kill hald cdrecord works perfectly.

> > > hmm, perhaps media polling confused your CD recorder?
 
> > This is why hald opens the cdrom devices with O_EXCL. From the hal
> > changelog:
 
> >    * hald/linux/block_class_device.c:
> >    (detect_media): use O_EXCL for optical drive media detection, much
> >    safer since O_EXCL is actually in mainline. Removes possible burning
> >    problems (that is, if only cdrecord open(2)'s the device using O_EXCL;
> >    bug filed against fedora-devel, hopefully it will bubble upstream)
> > 
> > I don't know if debian's cdrecord package uses O_EXCL, probably
> > not. So this bug should probably reassigned.  

> Just checked. Debians cdrecord indeed doesn't use O_EXCL. So i'm reassigning
> this bug. A patch can be found on
> http://people.mandrakesoft.com/~warly/files/cdrtools/

Wait a second, do I parse this correctly as: Hald was changed to use
O_EXCL because fedora uses a patched version of cdrecord which uses
O_EXCL? And now you propose to fix the fact that this causes unpatched
cdrecord to break by proposing that Debian's cdrecord is patched, too?
 
             cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Message #53 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Sjoerd Simons <sjoerd@spring.luon.net>

To: Andreas Metzler <ametzler@downhill.at.eu.org>

Cc: Martin Waitz <tali@admingilde.org>, 262678@bugs.debian.org, ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Thu, 9 Sep 2004 11:40:03 +0200

On Thu, Sep 09, 2004 at 10:39:26AM +0200, Andreas Metzler wrote:
> reassign 262678 hald cdrecord
> thanks
> On 2004-08-02 Sjoerd Simons <sjoerd@spring.luon.net> wrote:
> > reassign 262678 cdrecord
> > thanks
> 
> > On Mon, Aug 02, 2004 at 06:04:57PM +0200, Sjoerd Simons wrote:
> > > On Mon, Aug 02, 2004 at 11:49:10AM +0200, Martin Waitz wrote:
> > > > On Sun, Aug 01, 2004 at 01:51:50PM +0000, ROBERTOJIMENOCA wrote:
> > > > > With hald running there's a buffer underrun everytime I try.
> [...]
> > > > > When I kill hald cdrecord works perfectly.
> 
> > > > hmm, perhaps media polling confused your CD recorder?
>  
> > > This is why hald opens the cdrom devices with O_EXCL. From the hal
> > > changelog:
>  
> > >    * hald/linux/block_class_device.c:
> > >    (detect_media): use O_EXCL for optical drive media detection, much
> > >    safer since O_EXCL is actually in mainline. Removes possible burning
> > >    problems (that is, if only cdrecord open(2)'s the device using O_EXCL;
> > >    bug filed against fedora-devel, hopefully it will bubble upstream)
> > > 
> > > I don't know if debian's cdrecord package uses O_EXCL, probably
> > > not. So this bug should probably reassigned.  
> 
> > Just checked. Debians cdrecord indeed doesn't use O_EXCL. So i'm reassigning
> > this bug. A patch can be found on
> > http://people.mandrakesoft.com/~warly/files/cdrtools/
> 
> Wait a second, do I parse this correctly as: Hald was changed to use
> O_EXCL because fedora uses a patched version of cdrecord which uses
> O_EXCL? 

No. The problem is as follows. For hal to do media detection in cdrom drives it
needs to poll the drive, but when doing this while burning causes a problem  on
certain drives (the problem originally described in the bug report). 

To prevent this hal opens the cddrive with O_EXCL, but this only helps if other
programs also open the drive with O_EXCL to ensure ``exclusive'' access.

I hope this makes the problem somewhat more clear.  Can i reassign to cdrecord
again? Because we can't fix it on the hal side any more then this.

 Sjoerd
-- 
Perhaps the remembrance of these things will prove a source of future
pleasure.
		-- Virgil

Message #58 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: Sjoerd Simons <sjoerd@spring.luon.net>

Cc: Martin Waitz <tali@admingilde.org>, 262678@bugs.debian.org, ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Thu, 9 Sep 2004 12:03:35 +0200

On 2004-09-09 Sjoerd Simons <sjoerd@spring.luon.net> wrote:
> On Thu, Sep 09, 2004 at 10:39:26AM +0200, Andreas Metzler wrote:
[...] 
> > Wait a second, do I parse this correctly as: Hald was changed to use
> > O_EXCL because fedora uses a patched version of cdrecord which uses
> > O_EXCL? 

> No. The problem is as follows. For hal to do media detection in
> cdrom drives it needs to poll the drive, but when doing this while
> burning causes a problem  on certain drives (the problem originally
> described in the bug report). 

Hello,
This bugreport does not say anything about problems with hal without
O_EXCL.

The problem described in the bug-report was when using a version of
hal, which _was_ _already_ using O_EXCL.

O_EXCL was added to hal on 2004-07-20 (release 0.2.95).

Do you know how other DVD/cdrecording apps in Debian handle this?
(cdrdao, dvdrecord, libburn, dvd+rw-tools, ...)?
                  cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Message #63 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Sjoerd Simons <sjoerd@spring.luon.net>

To: Andreas Metzler <ametzler@downhill.at.eu.org>

Cc: 262678@bugs.debian.org, ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Thu, 9 Sep 2004 13:55:56 +0200

On Thu, Sep 09, 2004 at 12:03:35PM +0200, Andreas Metzler wrote:
> On 2004-09-09 Sjoerd Simons <sjoerd@spring.luon.net> wrote:
> > On Thu, Sep 09, 2004 at 10:39:26AM +0200, Andreas Metzler wrote:
> [...] 
> > > Wait a second, do I parse this correctly as: Hald was changed to use
> > > O_EXCL because fedora uses a patched version of cdrecord which uses
> > > O_EXCL? 
> 
> > No. The problem is as follows. For hal to do media detection in
> > cdrom drives it needs to poll the drive, but when doing this while
> > burning causes a problem  on certain drives (the problem originally
> > described in the bug report). 
> 
> Hello,
> This bugreport does not say anything about problems with hal without
> O_EXCL.
> 
> The problem described in the bug-report was when using a version of
> hal, which _was_ _already_ using O_EXCL.
>
> O_EXCL was added to hal on 2004-07-20 (release 0.2.95).

Ok, so i wasn't clear enough. The problem that the reporter was having is that
his drive doesn't handle the case that the media status is requested while
burning. Whether hal uses O_EXCL in it's open() or not doesn't matter for this. 

So why the O_EXCL then? Only one program at a time can use O_EXCL on a block
device. So when a cd burning tool opens the drive with O_EXCL, hal won't/can't
poll it thus the problematic behavour isn't triggered. Magicdev for example 
does the same thing as hal for the same reason. 
  
> Do you know how other DVD/cdrecording apps in Debian handle this?
> (cdrdao, dvdrecord, libburn, dvd+rw-tools, ...)?

The ones a looked just now didn't use O_EXCL yet. So this bug should be filed
for them too.

  Sjoerd
-- 
If you have to think twice about it, you're wrong.

Message #68 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Andreas Metzler <ametzler@downhill.at.eu.org>

To: Sjoerd Simons <sjoerd@spring.luon.net>, 262678@bugs.debian.org

Cc: ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Fri, 10 Sep 2004 09:06:11 +0200

reassign 262678 cdrecord
retitle 262678 cdrecord: Please use O_EXCL.
thanks
On 2004-09-09 Sjoerd Simons <sjoerd@spring.luon.net> wrote:
> On Thu, Sep 09, 2004 at 12:03:35PM +0200, Andreas Metzler wrote:
[...]
> Ok, so i wasn't clear enough. The problem that the reporter was
> having is that his drive doesn't handle the case that the media
> status is requested while burning. Whether hal uses O_EXCL in it's
> open() or not doesn't matter for this. 

> So why the O_EXCL then? Only one program at a time can use O_EXCL on
> a block device. So when a cd burning tool opens the drive with
> O_EXCL, hal won't/can't poll it thus the problematic behavour isn't
> triggered. Magicdev for example does the same thing as hal for the
> same reason.
[...]

Thank you for the explanation.
            cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"

Message #77 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <martin@piware.de>

To: 262678@bugs.debian.org

Subject: Ubuntu patch

Date: Tue, 28 Sep 2004 22:19:54 +0200

[Message part 1 (text/plain, inline)]

Hi!

I just uploaded a new Ubuntu version of cdrtools which fixes this. The
patch above was incomplete and also changed other things that weren't
exactly necessary.

You can get the dpatch from Ubuntu's bugzilla:
https://bugzilla.ubuntulinux.org/attachment.cgi?id=232

Bug report:
https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1864

This dpatch changes the identification string to something Ubuntu-ish
to comply to the license; you should change that to Debian, of course.
:-)

Thanks for considering and have a nice day!

Martin
-- 
Martin Pitt                       http://www.piware.de
Ubuntu Developer            http://www.ubuntulinux.org
Debian GNU/Linux Developer       http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Message #84 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <martin@piware.de>

To: 262678@bugs.debian.org

Subject: Updated patch available

Date: Tue, 19 Oct 2004 14:00:48 +0200

[Message part 1 (text/plain, inline)]

Hi!

I just updated the patch in our bugzilla. The previous version also
changed the open() calls for device probing (-scanbus), which is
unnecessary and annoying (see [1]).

The bug is still the same:

  https://bugzilla.ubuntulinux.org/show_bug.cgi?id=1864

The dpatch can be downloaded directly from:

  https://bugzilla.ubuntulinux.org/attachment.cgi?id=538

Thanks for considering!

Martin

[1] https://bugzilla.ubuntulinux.org/show_bug.cgi?id=2023
-- 
Martin Pitt                       http://www.piware.de
Ubuntu Developer            http://www.ubuntulinux.org
Debian GNU/Linux Developer       http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Message #89 received at 262678@bugs.debian.org (full text, mbox, reply):

From: Steve McIntyre <steve@einval.com>

To: 262678@bugs.debian.org

Cc: Martin Pitt <martin@piware.de>, Sjoerd Simons <sjoerd@spring.luon.net>, ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

Subject: Re: cdrecord: Please use O_EXCL

Date: Thu, 13 Jan 2005 20:54:52 +0000

[Message part 1 (text/plain, inline)]

Looks like this patch is sensible and should be applied - cdrecord
should open the drive with O_EXCL to ensure that nothing else can
interrupt its drive accesses. This is a reasonable thing to do...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Dasmohapatra

[signature.asc (application/pgp-signature, inline)]

Message #94 received at 262678-quiet@bugs.debian.org (full text, mbox, reply):

From: browaeys.alban@wanadoo.fr

To: 262678-quiet@bugs.debian.org, schilling@fokus.fraunhofer.de

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Wed, 9 Feb 2005 02:09:29 +0100

This is a followup for bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262678

I am not that confident hald is a perfect software. Though upstream take
all notes into account. I wondered if your information on how this is
 done on solaris could help improve the problem in the above bug.

> A volmgt SW that periodically (e.g. every 3 seconds) polls the drive with a
> Test Unit Ready and does not try to mount a device that does not have a 
> readable medium inserted (e.g. Solaris) does not disturb the writing process.

In the reported problem there was a medium in the drive .
Did you meant that if there was a cdrom in the drive it may
fails on solaris too ? Or readable medium is only for already
burnt cdrom ?
Could it retrieve more than if the unit is ready (i guess this
is when the drive is ready to read the cdrom), for example the
drive cache size, without breaking the burn process. 

Schuss
Alban Browaeys

Message #99 received at 262678-quiet@bugs.debian.org (full text, mbox, reply):

From: Joerg Schilling <schilling@fokus.fraunhofer.de>

To: schilling@fokus.fraunhofer.de, browaeys.alban@wanadoo.fr, 262678-quiet@bugs.debian.org

Subject: Re: Bug#262678: Prevents recording with a CDR drive

Date: Wed, 09 Feb 2005 14:54:48 +0100

browaeys.alban@wanadoo.fr wrote:

> This is a followup for bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262678
>
> I am not that confident hald is a perfect software. Though upstream take
> all notes into account. I wondered if your information on how this is
>  done on solaris could help improve the problem in the above bug.

What is hald?

> > A volmgt SW that periodically (e.g. every 3 seconds) polls the drive with a
> > Test Unit Ready and does not try to mount a device that does not have a 
> > readable medium inserted (e.g. Solaris) does not disturb the writing process.
>
> In the reported problem there was a medium in the drive .
> Did you meant that if there was a cdrom in the drive it may
> fails on solaris too ? Or readable medium is only for already
> burnt cdrom ?
> Could it retrieve more than if the unit is ready (i guess this
> is when the drive is ready to read the cdrom), for example the
> drive cache size, without breaking the burn process. 

As cdrecord waits 10 seconds before starting to write, there is absolutely
no problem on Solaris.

The Solaris vold will check the CD after at most 3 seconds and after 
it found that it is empty, it leaves it alone for cdrecord.

From that I have been reported, the volume management on Linux is not
friendly to other applications :-(, it should be fixed.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Message #104 received at 262678@bugs.debian.org (full text, mbox, reply):

From: ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

To: 262678@bugs.debian.org

Subject: Re: cdrecord: Please use O_EXCL.

Date: Thu, 21 Apr 2005 17:25:52 GMT

Is the O_EXCL patch going to be applied so this bug gets fixed?

Joerg Schilling wrote:
> browaeys.alban@wanadoo.fr wrote:
> > This is a followup for bug:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug&2678
> >
> > I am not that confident hald is a perfect software. Though upstream take
> > all notes into account. I wondered if your information on how this is
> >  done on solaris could help improve the problem in the above bug.
> 
> What is hald?

http://www.freedesktop.org/Software/hal

> > > A volmgt SW that periodically (e.g. every 3 seconds) polls the drive with a
> > > Test Unit Ready and does not try to mount a device that does not have a
> > > readable medium inserted (e.g. Solaris) does not disturb the writing process.

That hack of checking periodically is avoided in hald.

> > In the reported problem there was a medium in the drive .
> > Did you meant that if there was a cdrom in the drive it may
> > fails on solaris too ? Or readable medium is only for already
> > burnt cdrom ?
> > Could it retrieve more than if the unit is ready (i guess this
> > is when the drive is ready to read the cdrom), for example the
> > drive cache size, without breaking the burn process.
> 
> As cdrecord waits 10 seconds before starting to write, there is absolutely
> no problem on Solaris.

So the hack of waiting 10 seconds is for that!
Debian maintainer: we need to remove that 10 seconds wait.

> The Solaris vold will check the CD after at most 3 seconds and after
> it found that it is empty, it leaves it alone for cdrecord.

What a shit of hack solaris has!!!
That's why in a real OS the O_EXCL is needed!

> From that I have been reported, the volume management on Linux is not
> friendly to other applications :-(, it should be fixed.

OK, propose a valid fix, but a real fix, not the Solaris hack.

Joerg please give solutions instead of whining about solaris. If you
need to sell all your SUN stock just do it! ;-)

Message #111 received at 262678@bugs.debian.org (full text, mbox, reply):

From: ROBERTOJIMENOCA <ROBERTOJIMENOCA@terra.es>

To: 262678@bugs.debian.org

Subject: Re: cdrecord: Please use O_EXCL.

Date: Tue, 26 Apr 2005 07:58:30 GMT

hal is going to sarge:
http://packages.debian.org/hal
so this cdrecord fix needs to go to sarge.
I was wondering if you knew because you uploaded to experimental
instead to unstable.

Message #116 received at 262678-close@bugs.debian.org (full text, mbox, reply):

From: Eduard Bloch <blade@debian.org>

To: 262678-close@bugs.debian.org

Subject: Bug#262678: fixed in cdrtools 4:2.01+01a01-4

Date: Tue, 26 Apr 2005 05:17:19 -0400

Source: cdrtools
Source-Version: 4:2.01+01a01-4

We believe that the bug you reported is fixed in the latest version of
cdrtools, which is due to be installed in the Debian FTP archive:

cdda2wav_2.01+01a01-4_i386.deb
  to pool/main/c/cdrtools/cdda2wav_2.01+01a01-4_i386.deb
cdrecord_2.01+01a01-4_i386.deb
  to pool/main/c/cdrtools/cdrecord_2.01+01a01-4_i386.deb
cdrtools-doc_2.01+01a01-4_all.deb
  to pool/main/c/cdrtools/cdrtools-doc_2.01+01a01-4_all.deb
cdrtools_2.01+01a01-4.diff.gz
  to pool/main/c/cdrtools/cdrtools_2.01+01a01-4.diff.gz
cdrtools_2.01+01a01-4.dsc
  to pool/main/c/cdrtools/cdrtools_2.01+01a01-4.dsc
mkisofs_2.01+01a01-4_i386.deb
  to pool/main/c/cdrtools/mkisofs_2.01+01a01-4_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 262678@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Eduard Bloch <blade@debian.org> (supplier of updated cdrtools package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 26 Apr 2005 10:30:34 +0200
Source: cdrtools
Binary: cdrtools-doc cdda2wav mkisofs cdrecord
Architecture: source all i386
Version: 4:2.01+01a01-4
Distribution: unstable
Urgency: low
Maintainer: Joerg Jaspert <joerg@debian.org>
Changed-By: Eduard Bloch <blade@debian.org>
Description: 
 cdda2wav   - Creates WAV files from audio CDs
 cdrecord   - command line CD writing tool
 cdrtools-doc - Documentation for the cdrtools package-suite
 mkisofs    - Creates ISO-9660 CD-ROM filesystem images
Closes: 262678 291376
Changes: 
 cdrtools (4:2.01+01a01-4) unstable; urgency=low
 .
   * O_EXCL issue becoming hot, uploading to unstable
   * sync with Ubuntu Breezy (renamed as needed):
     + 23_o_excl.dpatch (replaced with Ubuntu's version, closes: #262678)
     + 24_debug_tmpfile.dpatch (secure file access in rscsi, closes: #291376)
     + 25_mkisofs_iconv_manpage.dpatch (explicit note about iconv support)
     + 26_author_locale.dpatch (replace ö in his name with an ascci
       transliteration)
Files: 
 f5f38c04fe7df13455077f7b4cb7aea0 716 otherosfs optional cdrtools_2.01+01a01-4.dsc
 20f39fbe1ca8a261e52d92da30c6fc31 114943 otherosfs optional cdrtools_2.01+01a01-4.diff.gz
 48a8a47a4c1be46cce294555bde67d3a 220032 doc optional cdrtools-doc_2.01+01a01-4_all.deb
 a31492042699a3091ac4a912cc3aa695 582066 otherosfs optional cdrecord_2.01+01a01-4_i386.deb
 5705d9efa361c3a41fffa8b4eca46449 530842 otherosfs optional mkisofs_2.01+01a01-4_i386.deb
 7357dd6ef1646d93cc8b44306d33cc1b 158690 sound optional cdda2wav_2.01+01a01-4_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCbgSq4QZIHu3wCMURArpAAJ4+Wc/00m09gk5RN7jdY7iRBz2q1gCghctJ
mPcAgVQq9fMTFKiW1RqLHJc=
=hT7c
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.