Re: cpio
Davy Gigan wrote: > > On Tue, 24 Sep 2002 10:03:27 +0200 > "Herve Gautier" <[EMAIL PROTECTED]> wrote: > > > En effet, c'est dans le man ! Je suis vraiment desole ! Je vais donc > > utiliser > > -H crc. > > > > Ceci dit, en "redescendant" un cpio avec des "truncating inode number", cela > > n'a pas l'air de gener en quoi que ce soit. Est-ce normal ? Est-ce que cpio > > utilise d'i-node en question lors du restore ??? > > Certainement pas : si sur une de tes partitions tu effaces un fichier > qui faisait partie d'une archive (admettons que son inode était 1000) > et qu'ensuite tu crées un autre fichier, le kernel (ou le système de > fichier plutôt) sait que l'inode du fichier qui vient d'être effacé (1000) > est libre ... pour gagner du temps, il va le réaffecter aussitôt pour ton > nouveau fichier. Résultat, si cpio utilise les numéros d'inodes, tu imagines > le bordel lors de la restauration ;-) Tout a fait d'accord ! > A priori cpio utilise sa cuisine interne pour indexer les fichiers, pas > les numéros d'inode du système. Donc cpio n'utilise les numeros d'i-nodes pour restaurer. A quoi lui servent-ils ? S'ils ne lui servent a rien, pourquoi les sauver, et nous prevenir qu'ils sont eventuellement tronquer ??? -- You don't dream, it's a Real Virtuality ! Professional e-mail : [EMAIL PROTECTED] Personal e-mail : [EMAIL PROTECTED]
Re: cpio
Davy Gigan wrote: > > On Mon, 23 Sep 2002 14:12:05 +0200 > "Herve Gautier" <[EMAIL PROTECTED]> wrote: > > > Je fais des backups avec l'util cpio > > find . | cpio --quiet -o > ... > > et j'obtiens pleins de messages de la forme: > > > > usr/doc/kernel-doc-2.2.14/stallion.txt: truncating inode number > > > > Quelqu'un sait-il pourquoi ? > Oui, cpio utilise par défaut le format bin (c.f. manpage) qui ne supporte > que les inode < 65535, dès qu'un numéro d'inode est supérieur, il râle > (fais un ls -i des fichiers source d'erreur pour vérifier). > Normalement l'option -H te permettra de changer cette option et de > prendre un format plus adapté à ton système de fichiers. > Sinon, tu peux toujours changer et utiliser tar ou rsync. > En effet, c'est dans le man ! Je suis vraiment desole ! Je vais donc utiliser -H crc. Ceci dit, en "redescendant" un cpio avec des "truncating inode number", cela n'a pas l'air de gener en quoi que ce soit. Est-ce normal ? Est-ce que cpio utilise d'i-node en question lors du restore ??? Merci d'avance. -- You don't dream, it's a Real Virtuality ! Professional e-mail : [EMAIL PROTECTED] Personal e-mail : [EMAIL PROTECTED]
cpio
Bonjour. Je fais des backups avec l'util cpio find . | cpio --quiet -o > ... et j'obtiens pleins de messages de la forme: usr/doc/kernel-doc-2.2.14/stallion.txt: truncating inode number Quelqu'un sait-il pourquoi ? Merci d'avance -- You don't dream, it's a Real Virtuality ! Professional e-mail : [EMAIL PROTECTED] Personal e-mail : [EMAIL PROTECTED]
Re: Cacher la sequence de boot
Loïc LECOEUR wrote: > > Bonjour > > Je voudrais cacher la sequence de boot texte au démarage par un pixmap de la > taille de l'écran, au même titre que faisait Aurora sur la Mandrake 8.2. > > est ce possible de prendre le linux_logo (le pingouin qui bois une biere au > démarage), de le changer de maniere a ce qu'il prenne tout l'écran, et donc > qu'il cache les écritures lors du boot ? > > Cordialement Il me semble que tu peux cacher les messages du noyau (2.4) avec un parametre "quiet" quelque chose. Pour cacher les messages de init (les run-levels), je ne sais pas trop, mais il faudrait regarder du cote de aurora effectivement. Il me semble que c'est directement integrer dans les script de run level... Pour afficher un logo, il y a 6 mois, je n'ai rien trouver pour le noyau 2.4. Il exite bootlogo (je crois que c'est le bon nom), qui permet de faire ca pour le 2.2, mais que tu peux facilement adpater. Il faut remplacer le /usr/src/linux/include/linux/linux_logo.h (et peut-etre mettre des "define" de la taille de l'image dans un autre fichier, je ne sais plus). Par contre l'image de boot est au format xmp (ca prend donc beaucoup de place) et est en statique dans le noyau (la taille du noyau augmente en consequence...). Voila, j'espere que cela aidera -- You don't dream, it's a Real Virtuality ! Professional e-mail : [EMAIL PROTECTED] Personal e-mail : [EMAIL PROTECTED]
Re: [HS] Deplacer un nombre important de fichiers
Je pense que cela vient de la taille du buffer du shell... Okki wrote: > > Salut à tous > > Donc voilà, j'ai un petit problème. Je souhaiterai déplacer un nombre > important de fichiers (plus de 9000), mais j'ai droit à l'erreur > suivante : > > $ mv -i --reply=no * /path/menant/au/repertoire/ > bash: /bin/mv: Liste d'arguments trop longue > > J'ai passé la valeur de /proc/sys/fs/file-max à un nombre supérieur à > celui du nombre de fichiers, sans que ca change quoi que ce soit. Vais > je devoir tenté de modifier la valeur des macros NR_OPEN dans les > fichiers fs.h et limits.h des sources du kernel, puis augmenter la > valeur de la macro NR_FILE dans fs.h ou existe t il une solution plus > simple ne nécessitant pas une recompilation du kernel ? :) > > Oui, je pourrai effectivement déplacer les fichiers en plusieurs fois, > mais bon, devant accomplir de telles tâches quotidiennement, un unique > mv serait plus simple :) > > Merci d'avance > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- You don't dream, it's a Real Virtuality ! Professional e-mail : [EMAIL PROTECTED] Personal e-mail : [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
