Antes de eu explicar por que você provavelmente não deveria querer isso, aqui está o que o os programas backend precisariam:
growisofs precisariam obter a opção -use-the-force-luke = notray. libburn precisaria obter sua função de API burn_drive_release () chamada com o parâmetro "eject" definido como 0.
Meu Brasero, bastante envelhecido, não oferece oportunidades de configuração para qualquer um desses plugins.
Agora, por que essa ejeção é normalmente necessária, a menos que você queira ler dados unicamente pela ajuda de transações SCSI diretas como funções de leitura da libburn faça:
Todos os programas de gravação usam no Linux a execução do comando SCSI ioctl (SG_IO). Este ioctl envia comandos SCSI para a unidade e recebe as respostas da unidade. Mas não é coordenado com o dispositivo de bloco i / o do Linux, que tem avaliou o estado médio antes da queimadura e depois ainda buffers este estado e possivelmente alguns blocos de dados do meio.
Ejetar o meio faz com que esses dados em buffer sejam descartados e carregados o meio provoca uma nova avaliação do novo estado médio. Após o movimento out-in, o kernel do Linux é capaz de montar o superbloco de sistema de arquivos escrito, ou para deixar o mkisofs ler os metadados de a sessão escrita anteriormente para a próxima sessão a ser escrita.
Nenhum outro método confiável é conhecido. Para minha teoria, ioctl (BLKRRPART) (por exemplo, via comando hdparm -z) faria o truque, se não descritores de arquivo de unidades ópticas seria rejeitada por __blkdev_reread_part () em block / ioctl.c antes da função rescan_partitions () em block / partition-generic.c pode chamar disk- > fops- > revalidate_disk ().