creer un iso 9660 fs et le monter et lecture/ecriture
19 réponses
Saïd
Bonjour,
Comment puis-je creer un fichier qui contient un file system de type ISO
9660 (ou hybrid) et le monter de maniere a pouvoir y mettre des fichiers
ou en enlever?
L'idee c'est de graver ce fichier sans avoir le probleme que j'expose
dans un autre post. Je sais que c'est possible puisque le Finder fait ca
automatiquement quand on lui demande de prendre en charge un CD-R qui vient
d'etre insere dans un graveur.
Je netrouve pas dans Disk Utility l'option pour creer une simple image iso
et non pas un une image disque avec table de partition. Meme si je demande
de creer une image pour CD...
Marche pas. il veut que un fichier et rien d'autre.
Ils sont chiants chez Apple, mais chiants, mais chiants... C'en est frustrant. Si on ne peux plus bidouiller meme en CLI, mais ou va-t-on?
Non, je n'irais pas leur acheter un putain d'iBook G4 avec 120Go de DD sous pretexte que leur OS n'est pas foutu de se servir d'un pipe.
Heu... mkisofs sait utiliser un pipe sous linux ? Oui.
Cela suppose que les données sont écrites séquentiellement du premier au dernier octet. Est-ce le cas ? Rien compris.
Quand on travaille avec un vrai fichier on peut écrire les octets dans l'ordre qu'on veut, par exemple revenir au début du fichier si on veut.
Avec un pipe on ne peut que les écrire les uns après les autres.
Quand j'étions jeune on appellait ça random-access pour le premier et sequential access pour le second.
C'est tout mais ça fait une sacré différence.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Marche pas. il veut que un fichier et rien d'autre.
Ils sont chiants chez Apple, mais chiants, mais chiants... C'en
est frustrant. Si on ne peux plus bidouiller meme en CLI, mais ou va-t-on?
Non, je n'irais pas leur acheter un putain d'iBook G4 avec 120Go de DD sous
pretexte que leur OS n'est pas foutu de se servir d'un pipe.
Heu... mkisofs sait utiliser un pipe sous linux ?
Oui.
Cela suppose que les données sont écrites séquentiellement du premier
au dernier octet. Est-ce le cas ?
Rien compris.
Quand on travaille avec un vrai fichier on peut écrire les octets dans
l'ordre qu'on veut, par exemple revenir au début du fichier si on
veut.
Avec un pipe on ne peut que les écrire les uns après les autres.
Quand j'étions jeune on appellait ça random-access pour le premier et
sequential access pour le second.
C'est tout mais ça fait une sacré différence.
FiLH
--
FiLH photography. A taste of freedom in a conventional world.
Web: http://www.filh.org e-mail filh@filh.org
FAQ fr.rec.photo : http://frp.parisv.com/
Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Marche pas. il veut que un fichier et rien d'autre.
Ils sont chiants chez Apple, mais chiants, mais chiants... C'en est frustrant. Si on ne peux plus bidouiller meme en CLI, mais ou va-t-on?
Non, je n'irais pas leur acheter un putain d'iBook G4 avec 120Go de DD sous pretexte que leur OS n'est pas foutu de se servir d'un pipe.
Heu... mkisofs sait utiliser un pipe sous linux ? Oui.
Cela suppose que les données sont écrites séquentiellement du premier au dernier octet. Est-ce le cas ? Rien compris.
Quand on travaille avec un vrai fichier on peut écrire les octets dans l'ordre qu'on veut, par exemple revenir au début du fichier si on veut.
Avec un pipe on ne peut que les écrire les uns après les autres.
Quand j'étions jeune on appellait ça random-access pour le premier et sequential access pour le second.
C'est tout mais ça fait une sacré différence.
FiLH
-- FiLH photography. A taste of freedom in a conventional world. Web: http://www.filh.org e-mail FAQ fr.rec.photo : http://frp.parisv.com/ Sitafoto la photo a Bordeaux : http://sitafoto.free.fr/
Patrick Stadelmann
In article , Saïd wrote:
pourtant mkisofs etait en train de remplir fifo.iso avec les infos qu'il faut.
On en revient à la question initiale : est-tu sûr que mkisofs écrit le fichier de manière séquentielle, et qu'il ne va pas par exemple commencer par créer un gros fichier vide, pour le remplir ensuite de manière non séquentielle ?
Patrick -- Patrick Stadelmann
In article <slrncdj5ls.mu.said@brian.lan>, Saïd <said@brian.lan> wrote:
pourtant mkisofs etait en train de remplir fifo.iso avec les infos qu'il
faut.
On en revient à la question initiale : est-tu sûr que mkisofs écrit le
fichier de manière séquentielle, et qu'il ne va pas par exemple
commencer par créer un gros fichier vide, pour le remplir ensuite de
manière non séquentielle ?
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
pourtant mkisofs etait en train de remplir fifo.iso avec les infos qu'il faut.
On en revient à la question initiale : est-tu sûr que mkisofs écrit le fichier de manière séquentielle, et qu'il ne va pas par exemple commencer par créer un gros fichier vide, pour le remplir ensuite de manière non séquentielle ?
Patrick -- Patrick Stadelmann
Saïd
Patrick Stadelmann :
In article , Saïd wrote:
pourtant mkisofs etait en train de remplir fifo.iso avec les infos qu'il faut.
On en revient à la question initiale : est-tu sûr que mkisofs écrit le fichier de manière séquentielle, et qu'il ne va pas par exemple commencer par créer un gros fichier vide, pour le remplir ensuite de manière non séquentielle ?
Extrait du man de cdrecord sous linux:
file that contains the prepared data for that track. If the argument is -', standard input is used for that track. Only one track may be taken from stdin.
extrait du man mkisofs sous linux:
-print-size Print estimated filesystem size and exit. This option is needed for Disk At Once mode and with some CD-R drives when piping directly into cdrecord. In this case it is needed to know the size of the filesystem before the actual CD-cre- ation is done. The option -print-size allows to get this size from a "dry-run" before the CD is actually written. Old versions of mkisofs did write this information (among other information) to stderr. As this turns out to be hard to parse, the number without any other information is now printed on stdout too. If you like to write a simple shell script, redirect stderr and catch the number from stdout. This may be done with:
-o filename is the name of the file to which the iso9660 filesystem image should be written. This can be a disk file, a tape drive, or it can correspond directly to the device name of the optical disc writer. If not specified, stdout is used. Note that the output can also be a block special device for a regular disk drive, in which case the disk partition can be mounted and examined to ensure that the premastering was done correctly.
(noter que l'on peut utiliser stdout comme sortie)
Et j'ai deja grave de cette maniere (piper mkisofs dans cdrecord) sous linux. cdrecord a besoin de savoir la taille du isofs quand il lit la piste depuis son entree standard. Je retrouverais bien les details si tu veux.
-- Saïd.
Patrick Stadelmann :
In article <slrncdj5ls.mu.said@brian.lan>, Saïd <said@brian.lan> wrote:
pourtant mkisofs etait en train de remplir fifo.iso avec les infos qu'il
faut.
On en revient à la question initiale : est-tu sûr que mkisofs écrit le
fichier de manière séquentielle, et qu'il ne va pas par exemple
commencer par créer un gros fichier vide, pour le remplir ensuite de
manière non séquentielle ?
Extrait du man de cdrecord sous linux:
file that contains the prepared data for that track. If
the argument is -', standard input is used for that
track. Only one track may be taken from stdin.
extrait du man mkisofs sous linux:
-print-size
Print estimated filesystem size and exit. This
option is needed for Disk At Once mode and with
some CD-R drives when piping directly into
cdrecord. In this case it is needed to know the
size of the filesystem before the actual CD-cre-
ation is done. The option -print-size allows to
get this size from a "dry-run" before the CD is
actually written. Old versions of mkisofs did
write this information (among other information) to
stderr. As this turns out to be hard to parse, the
number without any other information is now printed
on stdout too. If you like to write a simple shell
script, redirect stderr and catch the number from
stdout. This may be done with:
-o filename
is the name of the file to which the iso9660
filesystem image should be written. This can be a
disk file, a tape drive, or it can correspond
directly to the device name of the optical disc
writer. If not specified, stdout is used. Note
that the output can also be a block special device
for a regular disk drive, in which case the disk
partition can be mounted and examined to ensure
that the premastering was done correctly.
(noter que l'on peut utiliser stdout comme sortie)
Et j'ai deja grave de cette maniere (piper mkisofs dans cdrecord) sous
linux. cdrecord a besoin de savoir la taille du isofs quand il lit la piste
depuis son entree standard. Je retrouverais bien les details si tu veux.
pourtant mkisofs etait en train de remplir fifo.iso avec les infos qu'il faut.
On en revient à la question initiale : est-tu sûr que mkisofs écrit le fichier de manière séquentielle, et qu'il ne va pas par exemple commencer par créer un gros fichier vide, pour le remplir ensuite de manière non séquentielle ?
Extrait du man de cdrecord sous linux:
file that contains the prepared data for that track. If the argument is -', standard input is used for that track. Only one track may be taken from stdin.
extrait du man mkisofs sous linux:
-print-size Print estimated filesystem size and exit. This option is needed for Disk At Once mode and with some CD-R drives when piping directly into cdrecord. In this case it is needed to know the size of the filesystem before the actual CD-cre- ation is done. The option -print-size allows to get this size from a "dry-run" before the CD is actually written. Old versions of mkisofs did write this information (among other information) to stderr. As this turns out to be hard to parse, the number without any other information is now printed on stdout too. If you like to write a simple shell script, redirect stderr and catch the number from stdout. This may be done with:
-o filename is the name of the file to which the iso9660 filesystem image should be written. This can be a disk file, a tape drive, or it can correspond directly to the device name of the optical disc writer. If not specified, stdout is used. Note that the output can also be a block special device for a regular disk drive, in which case the disk partition can be mounted and examined to ensure that the premastering was done correctly.
(noter que l'on peut utiliser stdout comme sortie)
Et j'ai deja grave de cette maniere (piper mkisofs dans cdrecord) sous linux. cdrecord a besoin de savoir la taille du isofs quand il lit la piste depuis son entree standard. Je retrouverais bien les details si tu veux.
-- Saïd.
Patrick Stadelmann
In article , Saïd wrote:
extrait du man mkisofs sous linux:
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Patrick -- Patrick Stadelmann
In article <slrncdjfl0.oi.said@brian.lan>, Saïd <said@brian.lan> wrote:
extrait du man mkisofs sous linux:
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Patrick -- Patrick Stadelmann
Saïd
Patrick Stadelmann :
In article , Saïd wrote:
extrait du man mkisofs sous linux:
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Si certainement. Simplement c'est hdiutil qui va refuser de lire dans un pipe comme je l'ai montre dans un de mes derniers posts. Sous linux je pipe mkisofs dans cdrecord
Sous mac OS X je dois piper vers "hdiutil burn" qui ne fonctionne pas comme cdrecord sous linux.
-- Saïd.
Patrick Stadelmann :
In article <slrncdjfl0.oi.said@brian.lan>, Saïd <said@brian.lan> wrote:
extrait du man mkisofs sous linux:
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Si certainement. Simplement c'est hdiutil qui va refuser de lire dans un
pipe comme je l'ai montre dans un de mes derniers posts. Sous linux je pipe
mkisofs dans cdrecord
Sous mac OS X je dois piper vers "hdiutil burn" qui ne fonctionne pas comme
cdrecord sous linux.
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Si certainement. Simplement c'est hdiutil qui va refuser de lire dans un pipe comme je l'ai montre dans un de mes derniers posts. Sous linux je pipe mkisofs dans cdrecord
Sous mac OS X je dois piper vers "hdiutil burn" qui ne fonctionne pas comme cdrecord sous linux.
-- Saïd.
Patrick Stadelmann
In article , Saïd wrote:
Patrick Stadelmann :
In article , Saïd wrote:
extrait du man mkisofs sous linux:
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Si certainement. Simplement c'est hdiutil qui va refuser de lire dans un pipe comme je l'ai montre dans un de mes derniers posts. Sous linux je pipe mkisofs dans cdrecord
D'après le man que tu as posté, mkisofs peut graver directement :
"or it can correspond directly to the device name of the optical disc writer".
Patrick -- Patrick Stadelmann
In article <slrncdjg50.r9.said@brian.lan>, Saïd <said@brian.lan> wrote:
Patrick Stadelmann :
In article <slrncdjfl0.oi.said@brian.lan>, Saïd <said@brian.lan> wrote:
extrait du man mkisofs sous linux:
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Si certainement. Simplement c'est hdiutil qui va refuser de lire dans un
pipe comme je l'ai montre dans un de mes derniers posts. Sous linux je pipe
mkisofs dans cdrecord
D'après le man que tu as posté, mkisofs peut graver directement :
"or it can correspond directly to the device name of the optical disc
writer".
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Si certainement. Simplement c'est hdiutil qui va refuser de lire dans un pipe comme je l'ai montre dans un de mes derniers posts. Sous linux je pipe mkisofs dans cdrecord
D'après le man que tu as posté, mkisofs peut graver directement :
"or it can correspond directly to the device name of the optical disc writer".
Patrick -- Patrick Stadelmann
Saïd
Patrick Stadelmann :
In article , Saïd wrote:
Patrick Stadelmann :
In article , Saïd wrote:
extrait du man mkisofs sous linux:
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Si certainement. Simplement c'est hdiutil qui va refuser de lire dans un pipe comme je l'ai montre dans un de mes derniers posts. Sous linux je pipe mkisofs dans cdrecord
D'après le man que tu as posté, mkisofs peut graver directement :
"or it can correspond directly to the device name of the optical disc writer".
Ca m'ettonerait que ca marche aussi simplement le gravage. Sous linux je n'ai jamais essaye. Sous mac OS X je ne vois que disk1 comme device possible et j'ai brian:/Users/said root# cat image.iso >/dev/disk1 su: /dev/disk1: Permission denied
(note que je suis root quand je lance le cat...)
Je pense que leur phrase est un peu optimiste.
-- Saïd.
Patrick Stadelmann :
In article <slrncdjg50.r9.said@brian.lan>, Saïd <said@brian.lan> wrote:
Patrick Stadelmann :
In article <slrncdjfl0.oi.said@brian.lan>, Saïd <said@brian.lan> wrote:
extrait du man mkisofs sous linux:
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Si certainement. Simplement c'est hdiutil qui va refuser de lire dans un
pipe comme je l'ai montre dans un de mes derniers posts. Sous linux je pipe
mkisofs dans cdrecord
D'après le man que tu as posté, mkisofs peut graver directement :
"or it can correspond directly to the device name of the optical disc
writer".
Ca m'ettonerait que ca marche aussi simplement le gravage.
Sous linux je n'ai jamais essaye. Sous mac OS X je ne vois que disk1 comme
device possible et j'ai
brian:/Users/said root# cat image.iso >/dev/disk1
su: /dev/disk1: Permission denied
Et sous Mac OS X, mkisofs ne propose pas ces options ?
Si certainement. Simplement c'est hdiutil qui va refuser de lire dans un pipe comme je l'ai montre dans un de mes derniers posts. Sous linux je pipe mkisofs dans cdrecord
D'après le man que tu as posté, mkisofs peut graver directement :
"or it can correspond directly to the device name of the optical disc writer".
Ca m'ettonerait que ca marche aussi simplement le gravage. Sous linux je n'ai jamais essaye. Sous mac OS X je ne vois que disk1 comme device possible et j'ai brian:/Users/said root# cat image.iso >/dev/disk1 su: /dev/disk1: Permission denied
Marche pas. il veut que un fichier et rien d'autre.
Ils sont chiants chez Apple, mais chiants, mais chiants... C'en est frustrant. Si on ne peux plus bidouiller meme en CLI, mais ou va-t-on?
Non, je n'irais pas leur acheter un putain d'iBook G4 avec 120Go de DD sous pretexte que leur OS n'est pas foutu de se servir d'un pipe.
Heu... mkisofs sait utiliser un pipe sous linux ? Oui.
Cela suppose que les données sont écrites séquentiellement du premier au dernier octet. Est-ce le cas ? Rien compris.
Quand on travaille avec un vrai fichier on peut écrire les octets dans l'ordre qu'on veut, par exemple revenir au début du fichier si on veut.
Avec un pipe on ne peut que les écrire les uns après les autres.
Quand j'étions jeune on appellait ça random-access pour le premier et sequential access pour le second.
C'est tout mais ça fait une sacré différence.
OK. Entre cdrecord et mkisofs on peut, sous linux (ou tout systeme qui les fait tourner), s'en sortir en demandant d'abord a mkisofs de calculer seulement la taille du isofs qu'il va creer, puis transmettre la taille a cdrecord comme une option et il se debrouille avec ca.
En tout cas j'ai deja grave a la vole des CD sous linux, meme si mes souvenirs ne sont plus tres clairs (c'etait le temps ou 650Mo etaient beaucoup pour un DD et ou l'ecriture sur DD n'etait pas si immediate (aujourd'hui j'ai un DD de 80Go avec un debit de 50Mo/s contre 4Go et 2Mo/s en ce temps la)).
De toute facon mon graveur DVD a degage de l'iBook parce qu'il ne s'entend pas bien avec le pont IDE/FW (voir fr.*mac*materiel).
A l'avenir je vais faire des choses du genre
brian -$ mkisofs /repe/rtoire |ssh muad-dib cdrecord ...
(muad-dib est le PC/linux qui contient le graveur et brian mon iBook/Mac OS X)
Marche pas. il veut que un fichier et rien d'autre.
Ils sont chiants chez Apple, mais chiants, mais chiants... C'en
est frustrant. Si on ne peux plus bidouiller meme en CLI, mais ou va-t-on?
Non, je n'irais pas leur acheter un putain d'iBook G4 avec 120Go de DD sous
pretexte que leur OS n'est pas foutu de se servir d'un pipe.
Heu... mkisofs sait utiliser un pipe sous linux ?
Oui.
Cela suppose que les données sont écrites séquentiellement du premier
au dernier octet. Est-ce le cas ?
Rien compris.
Quand on travaille avec un vrai fichier on peut écrire les octets dans
l'ordre qu'on veut, par exemple revenir au début du fichier si on
veut.
Avec un pipe on ne peut que les écrire les uns après les autres.
Quand j'étions jeune on appellait ça random-access pour le premier et
sequential access pour le second.
C'est tout mais ça fait une sacré différence.
OK. Entre cdrecord et mkisofs on peut, sous linux (ou tout systeme qui les
fait tourner), s'en sortir en demandant d'abord a mkisofs de calculer
seulement la taille du isofs qu'il va creer, puis transmettre la taille a
cdrecord comme une option et il se debrouille avec ca.
En tout cas j'ai deja grave a la vole des CD sous linux, meme si mes
souvenirs ne sont plus tres clairs (c'etait le temps ou 650Mo etaient
beaucoup pour un DD et ou l'ecriture sur DD n'etait pas si immediate
(aujourd'hui j'ai un DD de 80Go avec un debit de 50Mo/s contre 4Go et
2Mo/s en ce temps la)).
De toute facon mon graveur DVD a degage de l'iBook parce qu'il ne s'entend
pas bien avec le pont IDE/FW (voir fr.*mac*materiel).
A l'avenir je vais faire des choses du genre
brian -$ mkisofs /repe/rtoire |ssh muad-dib cdrecord ...
(muad-dib est le PC/linux qui contient le graveur et brian mon iBook/Mac OS
X)
Marche pas. il veut que un fichier et rien d'autre.
Ils sont chiants chez Apple, mais chiants, mais chiants... C'en est frustrant. Si on ne peux plus bidouiller meme en CLI, mais ou va-t-on?
Non, je n'irais pas leur acheter un putain d'iBook G4 avec 120Go de DD sous pretexte que leur OS n'est pas foutu de se servir d'un pipe.
Heu... mkisofs sait utiliser un pipe sous linux ? Oui.
Cela suppose que les données sont écrites séquentiellement du premier au dernier octet. Est-ce le cas ? Rien compris.
Quand on travaille avec un vrai fichier on peut écrire les octets dans l'ordre qu'on veut, par exemple revenir au début du fichier si on veut.
Avec un pipe on ne peut que les écrire les uns après les autres.
Quand j'étions jeune on appellait ça random-access pour le premier et sequential access pour le second.
C'est tout mais ça fait une sacré différence.
OK. Entre cdrecord et mkisofs on peut, sous linux (ou tout systeme qui les fait tourner), s'en sortir en demandant d'abord a mkisofs de calculer seulement la taille du isofs qu'il va creer, puis transmettre la taille a cdrecord comme une option et il se debrouille avec ca.
En tout cas j'ai deja grave a la vole des CD sous linux, meme si mes souvenirs ne sont plus tres clairs (c'etait le temps ou 650Mo etaient beaucoup pour un DD et ou l'ecriture sur DD n'etait pas si immediate (aujourd'hui j'ai un DD de 80Go avec un debit de 50Mo/s contre 4Go et 2Mo/s en ce temps la)).
De toute facon mon graveur DVD a degage de l'iBook parce qu'il ne s'entend pas bien avec le pont IDE/FW (voir fr.*mac*materiel).
A l'avenir je vais faire des choses du genre
brian -$ mkisofs /repe/rtoire |ssh muad-dib cdrecord ...
(muad-dib est le PC/linux qui contient le graveur et brian mon iBook/Mac OS X)
