One thing I forgot to mention is that it can be reproduced every boot up of the system.

well this is a known bug to me, and won't be fixed.

The thing is that g-v-m polls the device every so much seconds, and no lock is set by cdrecord/cdrdao.
We applied a patch for it, so it will be locked this way g-v-m can't poll it any more and this problem arise.

If no patches are applied, the cd you will burn. will be corrupted afterwards. so my opinion is that a good cd is more important than a auto-mounter ;)

to quote : http://fy.chalmers.se/~appro/linux/DVD+RW/
If your burner unit is managed by some Linux(*) removable media automounting/autoplaying facility, such as autofs, supermount, subfs/submount, magicdev, autorun or similar, take it out of its control! I can't help you with the latter, check your system documentation (such as google perhaps:-) for specific instructions. Failure to take your unit out of Linux(*) automounting/autoplaying facility control can result in busted recording, a coaster! At the very least you have to make sure your unit is not automounted during recordings.
(*) dvd+rw-tools support Solaris volume manager and IRIX mediad in more gracious manner and it's safe to leave recorder under their control.

I hate to do this type of comparison, but I am a very recent slackware to arch convert, and I've most definately burnt good cd's with nautilus-cd-burner using hal/dbus, and had no problems re-recognizing newly inserted media with hal/dbus after the burn was complete.
If its possible in slack, it has to be possible in arch since the underlying technology (g-v-m/hal/dbus/edev) is the same.
I wouldn't mind testing a self compiled "unpatched" veresion of whatever package is patched in arch linux if you could just tell me which package is patched in arch.

Sorry, typo in above comment edev=udev...

try build cdrecord/cdrdao without patches...

Thanks will do that, and test several burns, Ill report back here after that.

One thing: the gnome-volume-manager we have at this moment is meant for gnome 2.10 but works on gnome 2.8. Maybe this could make a difference. Have you tried gnome in testing?

I tried rebuilding the cdrtools and cdrdao packages withouth the patch files and it didn't help.
Ill try the gnome packages from testing.

Before I go to testing gnome packages, can you give me any hint what other packages were patched for cd burning?
Or the reason why you are using gnome-v-m from 2.10 (only asking to see if I can go back to 2.8's g-v-m)

Ok, problem solved. I rebuilt the cdrtools, cdrdao without patches (except the utf patch), but this alone didn't seem to help. So I went ahead and rebuilt the gnome-v-m 1.0.3 package, it works like a charm, burning works just fine, and cd's get automounted again after burning a cd with nautilus-cd-burner.
Can anyone answer why Arch is using gnome 2.10's volume manager?

By the way, in case I wasn't clear enough, the cd's I burnt are fine, they are not corrupted in any way.

Does this still happen with gnome 2.10?

I havent used arch's 2.10 yet, however, I've used 2.10 under ubuntu hoary, and its working fine there.

Hi, just tried gnome 2.10 and the problem happens under 2.10
This can easily be confirmed as incorrect behaviour and defeats the purpose of project utopia.
Anything I can do to help please ask.

What is the status with current nautilus-cd-burner and hal 0.5?

Hmm, still able to reproduce this. When nautilus-cd-burner is finished burning CDs, gnome-vfs-daemon doesn't listen to HAL notifications anymore. Sending a HUP to gnome-vfs-daemon fixes this, but this is not the right thing to do ;)

Hi there,
Thanks for updating this, however I've switched to kde since I got a bit fed up with some bugs in gnome (not arch bugs, but gnome bugs) and can't update it anymore.

Ok, back to gnome again :D And thankfully in 2.12 its finally fixed!
This can be closed now.