How to prevent Brasero to auto eject disc at the end of burning?
Clash Royale CLAN TAG#URR8PPP up vote
0
down vote
favorite
I'm using Brasero to burn some disc. It works fine. But, at the end of burning, Brasero eject the disc each time. I wish to disable it and keep the disc in the disc drive at the end of burning, but there is no option to prevent the auto eject. How to avoid the auto eject of Brasero at the end of burngin ? Ubuntu 14.04, Brasero 3.10
brasero eject
asked Feb 7 at 6:28
NicolasSmith
3741215
add a comment |Â
up vote
0
down vote
favorite
I'm using Brasero to burn some disc. It works fine. But, at the end of burning, Brasero eject the disc each time. I wish to disable it and keep the disc in the disc drive at the end of burning, but there is no option to prevent the auto eject. How to avoid the auto eject of Brasero at the end of burngin ? Ubuntu 14.04, Brasero 3.10
brasero eject
asked Feb 7 at 6:28
NicolasSmith
3741215
Not sure if that is possible from what I see from my end!
– George Udosen
Feb 7 at 6:47
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm using Brasero to burn some disc. It works fine. But, at the end of burning, Brasero eject the disc each time. I wish to disable it and keep the disc in the disc drive at the end of burning, but there is no option to prevent the auto eject. How to avoid the auto eject of Brasero at the end of burngin ? Ubuntu 14.04, Brasero 3.10
brasero eject
asked Feb 7 at 6:28
NicolasSmith
3741215
I'm using Brasero to burn some disc. It works fine. But, at the end of burning, Brasero eject the disc each time. I wish to disable it and keep the disc in the disc drive at the end of burning, but there is no option to prevent the auto eject. How to avoid the auto eject of Brasero at the end of burngin ? Ubuntu 14.04, Brasero 3.10
brasero eject
brasero eject
asked Feb 7 at 6:28
NicolasSmith
3741215
asked Feb 7 at 6:28
NicolasSmith
3741215
asked Feb 7 at 6:28
NicolasSmith
3741215
asked Feb 7 at 6:28
NicolasSmith
3741215
asked Feb 7 at 6:28
NicolasSmith
3741215
3741215
Not sure if that is possible from what I see from my end!
– George Udosen
Feb 7 at 6:47
add a comment |Â
Not sure if that is possible from what I see from my end!
– George Udosen
Feb 7 at 6:47
Not sure if that is possible from what I see from my end!
– George Udosen
Feb 7 at 6:47
Not sure if that is possible from what I see from my end!
– George Udosen
Feb 7 at 6:47
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
Before i explain why you probably should not want this, here is what the
backend programs would need:
growisofs would need to get option -use-the-force-luke=notray .
libburn would need to get its API function burn_drive_release() called
with parameter "eject" set to 0.
My rather aged Brasero does not offer such configuration opportunities for
either of these plugins.
Now why this eject is normally needed unless you want to read the written
data solely by help of direct SCSI transactions as libburn's read functions
do:
All burn programs use on Linux the SCSI command execution ioctl(SG_IO).
This ioctl sends SCSI commands to the drive and receives the drive's replies.
But it is not coordinated with the block device i/o of Linux, which has
assessed the medium state before the burn and afterwards still buffers
this state and possibly some data blocks of the medium.
Ejecting the medium causes these buffered data to be discarded and loading
the medium causes a new assessment of the new medium state.
After the out-in move, the Linux kernel is able to mount the freshly
written filesystem superblock, or to let mkisofs read the metadata of
the previously written session for the next session to be written.
No other reliable method is known. To my theory, ioctl(BLKRRPART)
(e.g. via command hdparm -z) would do the trick, if not file descriptors
of optical drives would be rejected by __blkdev_reread_part() in
block/ioctl.c before the function rescan_partitions() in
block/partition-generic.c can call disk->fops->revalidate_disk().
answered Feb 7 at 11:50
Thomas Schmitt
67135
Sorry, it's incomprehensible. How to explain that in a language for a basic user ?
– NicolasSmith
Feb 7 at 19:34
Even if you find a way to do it: Do not do it.
– Thomas Schmitt
Feb 7 at 21:18
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
Before i explain why you probably should not want this, here is what the
backend programs would need:
growisofs would need to get option -use-the-force-luke=notray .
libburn would need to get its API function burn_drive_release() called
with parameter "eject" set to 0.
My rather aged Brasero does not offer such configuration opportunities for
either of these plugins.
Now why this eject is normally needed unless you want to read the written
data solely by help of direct SCSI transactions as libburn's read functions
do:
All burn programs use on Linux the SCSI command execution ioctl(SG_IO).
This ioctl sends SCSI commands to the drive and receives the drive's replies.
But it is not coordinated with the block device i/o of Linux, which has
assessed the medium state before the burn and afterwards still buffers
this state and possibly some data blocks of the medium.
Ejecting the medium causes these buffered data to be discarded and loading
the medium causes a new assessment of the new medium state.
After the out-in move, the Linux kernel is able to mount the freshly
written filesystem superblock, or to let mkisofs read the metadata of
the previously written session for the next session to be written.
No other reliable method is known. To my theory, ioctl(BLKRRPART)
(e.g. via command hdparm -z) would do the trick, if not file descriptors
of optical drives would be rejected by __blkdev_reread_part() in
block/ioctl.c before the function rescan_partitions() in
block/partition-generic.c can call disk->fops->revalidate_disk().
answered Feb 7 at 11:50
Thomas Schmitt
67135
Sorry, it's incomprehensible. How to explain that in a language for a basic user ?
– NicolasSmith
Feb 7 at 19:34
Even if you find a way to do it: Do not do it.
– Thomas Schmitt
Feb 7 at 21:18
add a comment |Â
up vote
1
down vote
Before i explain why you probably should not want this, here is what the
backend programs would need:
growisofs would need to get option -use-the-force-luke=notray .
libburn would need to get its API function burn_drive_release() called
with parameter "eject" set to 0.
My rather aged Brasero does not offer such configuration opportunities for
either of these plugins.
Now why this eject is normally needed unless you want to read the written
data solely by help of direct SCSI transactions as libburn's read functions
do:
All burn programs use on Linux the SCSI command execution ioctl(SG_IO).
This ioctl sends SCSI commands to the drive and receives the drive's replies.
But it is not coordinated with the block device i/o of Linux, which has
assessed the medium state before the burn and afterwards still buffers
this state and possibly some data blocks of the medium.
Ejecting the medium causes these buffered data to be discarded and loading
the medium causes a new assessment of the new medium state.
After the out-in move, the Linux kernel is able to mount the freshly
written filesystem superblock, or to let mkisofs read the metadata of
the previously written session for the next session to be written.
No other reliable method is known. To my theory, ioctl(BLKRRPART)
(e.g. via command hdparm -z) would do the trick, if not file descriptors
of optical drives would be rejected by __blkdev_reread_part() in
block/ioctl.c before the function rescan_partitions() in
block/partition-generic.c can call disk->fops->revalidate_disk().
answered Feb 7 at 11:50
Thomas Schmitt
67135
Sorry, it's incomprehensible. How to explain that in a language for a basic user ?
– NicolasSmith
Feb 7 at 19:34
Even if you find a way to do it: Do not do it.
– Thomas Schmitt
Feb 7 at 21:18
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Before i explain why you probably should not want this, here is what the
backend programs would need:
growisofs would need to get option -use-the-force-luke=notray .
libburn would need to get its API function burn_drive_release() called
with parameter "eject" set to 0.
My rather aged Brasero does not offer such configuration opportunities for
either of these plugins.
Now why this eject is normally needed unless you want to read the written
data solely by help of direct SCSI transactions as libburn's read functions
do:
All burn programs use on Linux the SCSI command execution ioctl(SG_IO).
This ioctl sends SCSI commands to the drive and receives the drive's replies.
But it is not coordinated with the block device i/o of Linux, which has
assessed the medium state before the burn and afterwards still buffers
this state and possibly some data blocks of the medium.
Ejecting the medium causes these buffered data to be discarded and loading
the medium causes a new assessment of the new medium state.
After the out-in move, the Linux kernel is able to mount the freshly
written filesystem superblock, or to let mkisofs read the metadata of
the previously written session for the next session to be written.
No other reliable method is known. To my theory, ioctl(BLKRRPART)
(e.g. via command hdparm -z) would do the trick, if not file descriptors
of optical drives would be rejected by __blkdev_reread_part() in
block/ioctl.c before the function rescan_partitions() in
block/partition-generic.c can call disk->fops->revalidate_disk().
answered Feb 7 at 11:50
Thomas Schmitt
67135
Before i explain why you probably should not want this, here is what the
backend programs would need:
growisofs would need to get option -use-the-force-luke=notray .
libburn would need to get its API function burn_drive_release() called
with parameter "eject" set to 0.
My rather aged Brasero does not offer such configuration opportunities for
either of these plugins.
Now why this eject is normally needed unless you want to read the written
data solely by help of direct SCSI transactions as libburn's read functions
do:
All burn programs use on Linux the SCSI command execution ioctl(SG_IO).
This ioctl sends SCSI commands to the drive and receives the drive's replies.
But it is not coordinated with the block device i/o of Linux, which has
assessed the medium state before the burn and afterwards still buffers
this state and possibly some data blocks of the medium.
Ejecting the medium causes these buffered data to be discarded and loading
the medium causes a new assessment of the new medium state.
After the out-in move, the Linux kernel is able to mount the freshly
written filesystem superblock, or to let mkisofs read the metadata of
the previously written session for the next session to be written.
No other reliable method is known. To my theory, ioctl(BLKRRPART)
(e.g. via command hdparm -z) would do the trick, if not file descriptors
of optical drives would be rejected by __blkdev_reread_part() in
block/ioctl.c before the function rescan_partitions() in
block/partition-generic.c can call disk->fops->revalidate_disk().
answered Feb 7 at 11:50
Thomas Schmitt
67135
answered Feb 7 at 11:50
Thomas Schmitt
67135
answered Feb 7 at 11:50
Thomas Schmitt
67135
answered Feb 7 at 11:50
Thomas Schmitt
67135
67135
Sorry, it's incomprehensible. How to explain that in a language for a basic user ?
– NicolasSmith
Feb 7 at 19:34
Even if you find a way to do it: Do not do it.
– Thomas Schmitt
Feb 7 at 21:18
add a comment |Â
Sorry, it's incomprehensible. How to explain that in a language for a basic user ?
– NicolasSmith
Feb 7 at 19:34
Even if you find a way to do it: Do not do it.
– Thomas Schmitt
Feb 7 at 21:18
Sorry, it's incomprehensible. How to explain that in a language for a basic user ?
– NicolasSmith
Feb 7 at 19:34
Sorry, it's incomprehensible. How to explain that in a language for a basic user ?
– NicolasSmith
Feb 7 at 19:34
Even if you find a way to do it: Do not do it.
– Thomas Schmitt
Feb 7 at 21:18
Even if you find a way to do it: Do not do it.
– Thomas Schmitt
Feb 7 at 21:18
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1003774%2fhow-to-prevent-brasero-to-auto-eject-disc-at-the-end-of-burning%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Not sure if that is possible from what I see from my end!
– George Udosen
Feb 7 at 6:47