J'ai une liste de fichiers stockée dans un fichier texte .
Mon but est de créer des iso de ces fichiers pour les graver.
La taille totale de tous ces fichiers occuperai environ 4 CD-rom .
Avec un script shell ( preference pour zsh ) je souhaite faire les iso qui
conviennent.
il y a plusieurs façons de faire :
1°) faire une somme partielle des tailles des N premiers fichiers puis
s'arreter quand on atteint 700 MBytes et ensuite faire un iso (avec
mkisofs ) de ces N premiers fichiers ( et continuer jusqu'a la fin de la
liste) . Dans ce cas , est ce que l'iso obtenu sera ( sensiblement ) de la
meme taille que l'ensemble des N fichiers réunis ?
2°) faire directement l'iso en insérant un par un les fichiers dans l'iso
( est-ce possible ? quelle syntaxe ? ) et s'arreter d'inserer quand l'iso
atteint 700MBytes ...
Je ne souhaite pas utiliser l'otion de faire une archive qu'on va splitter
ensuite , parceque j'ai besoin d'avoir les fichiers en clair sur le
CD-Rom .
Auriez-vous une piste pour que je puisse mener a bien cette tache s'il vous
plait ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul GABORIT
À (at) Mon, 23 Feb 2004 08:20:15 +0100, Rakotomandimby écrivait (wrote):
il y a plusieurs façons de faire : 1°) faire une somme partielle des tailles des N premiers fichiers puis s'arreter quand on atteint 700 MBytes et ensuite faire un iso (avec mkisofs ) de ces N premiers fichiers ( et continuer jusqu'a la fin de la liste) . Dans ce cas , est ce que l'iso obtenu sera ( sensiblement ) de la meme taille que l'ensemble des N fichiers réunis ? 2°) faire directement l'iso en insérant un par un les fichiers dans l'iso ( est-ce possible ? quelle syntaxe ? ) et s'arreter d'inserer quand l'iso atteint 700MBytes ...
Il y a une toute petite différence entre la taille de l'image et la somme des tailles des fichiers qui la composent. Mais c'est négligeable. D'autant qu'on fait tenir un peu plus que 700Mo sur un CD-R(W)-700Mo. Si vous ne voulez courir aucun risque, vous fixez arbitrairement la limite à 690Mo et on en parle plus.
Par contre, votre problème est un problème du type "sac à dos" : quel est le meilleur rangement ? Et votre méthode (algorithme) n'y répond pas de manière adéquate. Un petit exemple avec la liste suivante :
fichier taille A 351Mo B 351Mo C 340Mo D 340Mo
Avec votre méthode, vous obtenez :
CD1: A (351Mo - si on ajoute B, on dépasse de 2Mo) CD2: B, C (691Mo - si on ajoute D, on dépasse de 339Mo) CD3: D (340Mo)
Avec un bon algorithme, vous obtiendriez :
CD1: A, C (691Mo) CD2: B, D (691Mo)
Vous avez économisé un CD, mais les fichiers ne sont plus dans l'ordre initial de la liste...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Mon, 23 Feb 2004 08:20:15 +0100,
Rakotomandimby <mrakotom@free.fr> écrivait (wrote):
il y a plusieurs façons de faire :
1°) faire une somme partielle des tailles des N premiers fichiers puis
s'arreter quand on atteint 700 MBytes et ensuite faire un iso (avec
mkisofs ) de ces N premiers fichiers ( et continuer jusqu'a la fin de la
liste) . Dans ce cas , est ce que l'iso obtenu sera ( sensiblement ) de la
meme taille que l'ensemble des N fichiers réunis ?
2°) faire directement l'iso en insérant un par un les fichiers dans l'iso
( est-ce possible ? quelle syntaxe ? ) et s'arreter d'inserer quand l'iso
atteint 700MBytes ...
Il y a une toute petite différence entre la taille de l'image et la somme des
tailles des fichiers qui la composent. Mais c'est négligeable. D'autant qu'on
fait tenir un peu plus que 700Mo sur un CD-R(W)-700Mo. Si vous ne voulez courir
aucun risque, vous fixez arbitrairement la limite à 690Mo et on en parle plus.
Par contre, votre problème est un problème du type "sac à dos" : quel est le
meilleur rangement ? Et votre méthode (algorithme) n'y répond pas de manière
adéquate. Un petit exemple avec la liste suivante :
fichier taille
A 351Mo
B 351Mo
C 340Mo
D 340Mo
Avec votre méthode, vous obtenez :
CD1: A (351Mo - si on ajoute B, on dépasse de 2Mo)
CD2: B, C (691Mo - si on ajoute D, on dépasse de 339Mo)
CD3: D (340Mo)
Avec un bon algorithme, vous obtiendriez :
CD1: A, C (691Mo)
CD2: B, D (691Mo)
Vous avez économisé un CD, mais les fichiers ne sont plus dans l'ordre initial
de la liste...
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Mon, 23 Feb 2004 08:20:15 +0100, Rakotomandimby écrivait (wrote):
il y a plusieurs façons de faire : 1°) faire une somme partielle des tailles des N premiers fichiers puis s'arreter quand on atteint 700 MBytes et ensuite faire un iso (avec mkisofs ) de ces N premiers fichiers ( et continuer jusqu'a la fin de la liste) . Dans ce cas , est ce que l'iso obtenu sera ( sensiblement ) de la meme taille que l'ensemble des N fichiers réunis ? 2°) faire directement l'iso en insérant un par un les fichiers dans l'iso ( est-ce possible ? quelle syntaxe ? ) et s'arreter d'inserer quand l'iso atteint 700MBytes ...
Il y a une toute petite différence entre la taille de l'image et la somme des tailles des fichiers qui la composent. Mais c'est négligeable. D'autant qu'on fait tenir un peu plus que 700Mo sur un CD-R(W)-700Mo. Si vous ne voulez courir aucun risque, vous fixez arbitrairement la limite à 690Mo et on en parle plus.
Par contre, votre problème est un problème du type "sac à dos" : quel est le meilleur rangement ? Et votre méthode (algorithme) n'y répond pas de manière adéquate. Un petit exemple avec la liste suivante :
fichier taille A 351Mo B 351Mo C 340Mo D 340Mo
Avec votre méthode, vous obtenez :
CD1: A (351Mo - si on ajoute B, on dépasse de 2Mo) CD2: B, C (691Mo - si on ajoute D, on dépasse de 339Mo) CD3: D (340Mo)
Avec un bon algorithme, vous obtiendriez :
CD1: A, C (691Mo) CD2: B, D (691Mo)
Vous avez économisé un CD, mais les fichiers ne sont plus dans l'ordre initial de la liste...
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Rakotomandimby
Paul GABORIT wrote:
Par contre, votre problème est un problème du type "sac à dos" : quel est le meilleur rangement ? Et votre méthode (algorithme) n'y répond pas de manière adéquate. Un petit exemple avec la liste suivante :
Un autre contributeur qui m'a repondu directement par mail m'a aussi evoqué ce souci .J'en ai tenu compte et un rapide controle a coup de find + ls -l + awk pour determiner le max m'a montré que la taille MAX d'un fichier est de 9Mo .
Je pense que je n'y perdrai pas beaucoup .
Donc un algo simpliste comme celui la suffira largement. Cela dit pour maculture generale , je me verrai bien en train de resoudre le souci du sac a dos :-)
Merci de vos contributions qui m'aident beaucoup -- Rakotomandimby Mihamina Andrianifaharana Tel : +33 2 38 76 43 65 http://stko.dyndns.info/site_principal/Members/mihamina
Paul GABORIT wrote:
Par contre, votre problème est un problème du type "sac à dos" : quel est
le meilleur rangement ? Et votre méthode (algorithme) n'y répond pas de
manière adéquate. Un petit exemple avec la liste suivante :
Un autre contributeur qui m'a repondu directement par mail m'a aussi evoqué
ce souci .J'en ai tenu compte et un rapide controle a coup de find + ls -l
+ awk pour determiner le max m'a montré que la taille MAX d'un fichier est
de 9Mo .
Je pense que je n'y perdrai pas beaucoup .
Donc un algo simpliste comme celui la suffira largement. Cela dit pour
maculture generale , je me verrai bien en train de resoudre le souci du sac
a dos :-)
Merci de vos contributions qui m'aident beaucoup
--
Rakotomandimby Mihamina Andrianifaharana
Tel : +33 2 38 76 43 65
http://stko.dyndns.info/site_principal/Members/mihamina
Par contre, votre problème est un problème du type "sac à dos" : quel est le meilleur rangement ? Et votre méthode (algorithme) n'y répond pas de manière adéquate. Un petit exemple avec la liste suivante :
Un autre contributeur qui m'a repondu directement par mail m'a aussi evoqué ce souci .J'en ai tenu compte et un rapide controle a coup de find + ls -l + awk pour determiner le max m'a montré que la taille MAX d'un fichier est de 9Mo .
Je pense que je n'y perdrai pas beaucoup .
Donc un algo simpliste comme celui la suffira largement. Cela dit pour maculture generale , je me verrai bien en train de resoudre le souci du sac a dos :-)
Merci de vos contributions qui m'aident beaucoup -- Rakotomandimby Mihamina Andrianifaharana Tel : +33 2 38 76 43 65 http://stko.dyndns.info/site_principal/Members/mihamina
Nicolas Le Scouarnec
Donc un algo simpliste comme celui la suffira largement. Cela dit pour maculture generale , je me verrai bien en train de resoudre le souci du sac a dos :-)
Peut etre en placant d'abord les fichiers les plus gros, en s'arrangeant pour occuper le moins de CD possible, puis inserer les fichiers moins gros, en occupant toujours le moins de CD possible et ainsi de suite jusqu'a ce qu'il n'y ait plus de fichiers a ajouter. Je ne sais pas si c'est la meilleure, mais c'est déja une possibilité.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Donc un algo simpliste comme celui la suffira largement. Cela dit pour
maculture generale , je me verrai bien en train de resoudre le souci du sac
a dos :-)
Peut etre en placant d'abord les fichiers les plus gros, en
s'arrangeant pour occuper le moins de CD possible, puis inserer les
fichiers moins gros, en occupant toujours le moins de CD possible et
ainsi de suite jusqu'a ce qu'il n'y ait plus de fichiers a ajouter. Je
ne sais pas si c'est la meilleure, mais c'est déja une possibilité.
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Donc un algo simpliste comme celui la suffira largement. Cela dit pour maculture generale , je me verrai bien en train de resoudre le souci du sac a dos :-)
Peut etre en placant d'abord les fichiers les plus gros, en s'arrangeant pour occuper le moins de CD possible, puis inserer les fichiers moins gros, en occupant toujours le moins de CD possible et ainsi de suite jusqu'a ce qu'il n'y ait plus de fichiers a ajouter. Je ne sais pas si c'est la meilleure, mais c'est déja une possibilité.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Sébastien Kirche
On 23 fév 2004, wrote:
Donc un algo simpliste comme celui la suffira largement. Cela dit pour maculture generale , je me verrai bien en train de resoudre le souci du sac a dos :-)
Résoudre est un bien grand mot, amha l'appréhender simplement ne serait déjà pas mal :)
Ce genre de problème d'utilisation optimale de l'espace, et de rangement constitue en effet tout un pan de l'algorithmique...
Pour info, il existe un logiciel (certes windows) dont le but est de parvenir au remplissage optimal de supports de stokage : BTTB (Burn to the Brim, littérallement : graver jusqu'à la tranche). D'ailleurs il s'occupe de remplir des images disque gravées par cdrecord.
J'en parle ici car c'est disponible sur sourceforge; le code source étant il me semble en Delphi. Peut-être qu'y jeter un coup d'oeil pourrait t'aider ?
Sinon j'ai perdu ma page qui contenait de précieux liens vers ce genre de problèmes avec leur implémentations. Si toutefaois cela t'intéresse, Google sera ton ami. Mot clés : knapsack (sac de campeur), optimisation combinatoire, optimisation discrète, optimisation linéaire.
Merci de vos contributions qui m'aident beaucoup
J'espère que cela fera avancer ton schmilblick ;)
Sébastien Kirche
On 23 fév 2004, mrakotom@free.fr wrote:
Donc un algo simpliste comme celui la suffira largement. Cela dit pour
maculture generale , je me verrai bien en train de resoudre le souci du
sac a dos :-)
Résoudre est un bien grand mot, amha l'appréhender simplement ne serait déjà
pas mal :)
Ce genre de problème d'utilisation optimale de l'espace, et de rangement
constitue en effet tout un pan de l'algorithmique...
Pour info, il existe un logiciel (certes windows) dont le but est de
parvenir au remplissage optimal de supports de stokage : BTTB (Burn to the
Brim, littérallement : graver jusqu'à la tranche).
D'ailleurs il s'occupe de remplir des images disque gravées par cdrecord.
J'en parle ici car c'est disponible sur sourceforge; le code source étant il
me semble en Delphi.
Peut-être qu'y jeter un coup d'oeil pourrait t'aider ?
Sinon j'ai perdu ma page qui contenait de précieux liens vers ce genre de
problèmes avec leur implémentations.
Si toutefaois cela t'intéresse, Google sera ton ami.
Mot clés : knapsack (sac de campeur), optimisation combinatoire,
optimisation discrète, optimisation linéaire.
Donc un algo simpliste comme celui la suffira largement. Cela dit pour maculture generale , je me verrai bien en train de resoudre le souci du sac a dos :-)
Résoudre est un bien grand mot, amha l'appréhender simplement ne serait déjà pas mal :)
Ce genre de problème d'utilisation optimale de l'espace, et de rangement constitue en effet tout un pan de l'algorithmique...
Pour info, il existe un logiciel (certes windows) dont le but est de parvenir au remplissage optimal de supports de stokage : BTTB (Burn to the Brim, littérallement : graver jusqu'à la tranche). D'ailleurs il s'occupe de remplir des images disque gravées par cdrecord.
J'en parle ici car c'est disponible sur sourceforge; le code source étant il me semble en Delphi. Peut-être qu'y jeter un coup d'oeil pourrait t'aider ?
Sinon j'ai perdu ma page qui contenait de précieux liens vers ce genre de problèmes avec leur implémentations. Si toutefaois cela t'intéresse, Google sera ton ami. Mot clés : knapsack (sac de campeur), optimisation combinatoire, optimisation discrète, optimisation linéaire.
Merci de vos contributions qui m'aident beaucoup
J'espère que cela fera avancer ton schmilblick ;)
Sébastien Kirche
JustMe
Sébastien Kirche wrote:
On 23 fév 2004, wrote:
Donc un algo simpliste comme celui la suffira largement. Cela dit pour maculture generale , je me verrai bien en train de resoudre le souci du sac a dos :-)
Résoudre est un bien grand mot, amha l'appréhender simplement ne serait déjà pas mal :)
Euh
Question con : pourquoi ne fais tu pas un tar multivolume qui remplira completement chacun des CDs ?
Sébastien Kirche wrote:
On 23 fév 2004, mrakotom@free.fr wrote:
Donc un algo simpliste comme celui la suffira largement. Cela dit pour
maculture generale , je me verrai bien en train de resoudre le souci du
sac a dos :-)
Résoudre est un bien grand mot, amha l'appréhender simplement ne serait déjà
pas mal :)
Euh
Question con : pourquoi ne fais tu pas un tar multivolume qui remplira
completement chacun des CDs ?
Donc un algo simpliste comme celui la suffira largement. Cela dit pour maculture generale , je me verrai bien en train de resoudre le souci du sac a dos :-)
Résoudre est un bien grand mot, amha l'appréhender simplement ne serait déjà pas mal :)
Euh
Question con : pourquoi ne fais tu pas un tar multivolume qui remplira completement chacun des CDs ?
Rakotomandimby
JustMe wrote:
Question con : pourquoi ne fais tu pas un tar multivolume qui remplira completement chacun des CDs ?
le cahier des charge "impose" que les fichiers ne soient pas archivés ni compressés mais directement lisibles ... sinon, effectivement j'aurai meme fait une grooooosssssssse archive, que j'aurai splitté ... :-) -- Rakotomandimby Mihamina Andrianifaharana Tel : +33 2 38 76 43 65 http://stko.dyndns.info/site_principal/Members/mihamina
JustMe wrote:
Question con : pourquoi ne fais tu pas un tar multivolume qui remplira
completement chacun des CDs ?
le cahier des charge "impose" que les fichiers ne soient pas archivés ni
compressés mais directement lisibles ... sinon, effectivement j'aurai meme
fait une grooooosssssssse archive, que j'aurai splitté ... :-)
--
Rakotomandimby Mihamina Andrianifaharana
Tel : +33 2 38 76 43 65
http://stko.dyndns.info/site_principal/Members/mihamina
Question con : pourquoi ne fais tu pas un tar multivolume qui remplira completement chacun des CDs ?
le cahier des charge "impose" que les fichiers ne soient pas archivés ni compressés mais directement lisibles ... sinon, effectivement j'aurai meme fait une grooooosssssssse archive, que j'aurai splitté ... :-) -- Rakotomandimby Mihamina Andrianifaharana Tel : +33 2 38 76 43 65 http://stko.dyndns.info/site_principal/Members/mihamina
