Bonjour à tous,
j'ai «profité» de la perte de ma boite de vitesse et de me retrouver coincé à Broome (Nord-Ouest de l'Australie... mais ne vous inquiétez pas, je profite aussi de la plage) pour avancer un petit projet que je voulais faire depuis longtemps.
gcp (Goffi's CoPier) est un outil de copie en ligne de commande à la cp, avec les quelques améliorations:
- une barre de progression (me souviens avoir vu un patch traîner à une époque sur gentoo pour en mettre une à cp, mais ce n'est pas en standard, c'est dommage)
- gcp continue la copie même en cas d'erreur: il saute juste le fichier en cause
- journalisation: les opérations sont écrites. Ainsi après la copie, vous pouvez savoir ce qui a été effectivement copié, ou si quelque chose a échoué. Typiquement, si vous essayez de copier un fichier root sans l'être, votre fichier sera copié (si les permissions vous l'autorisent), mais le changement de propriétaire ne sera pas possible: le journal affichera alors "PARTIAL: preserve-owner" ce qui signifie que la copie a fonctionné, mais pas le --preserve owner
- correction des noms de fichiers en cas d'incompatibilité avec le système de fichiers cible. Le cas typique, c'est la copie d'une fichier avec un "?", un "*" ou autre caractère interdit vers un disque en FAT. Avec cp ça ne marche pas, gcp corrige le nom pour que ça passe quand même... J'ai entendu «killer feature» dans la salle ?
- gcp ne gère qu'une queue de fichiers: si vous lancer une autre copie, gcp détectera l'autre instance et ajoutera ses fichiers à la première copie. Ainsi ça évitera à la tête de lecture de vos disques durs de faire des ballades tout le temps, et vous pouvez prévoir la fin de la copie plus facilement. Autre avantage: vous pouvez commencer une copie, pendant que vous cherchez d'autres fichiers à ajouter.
- possibilité de sauver la liste des fichiers sources. Le cas typique c'est si vous copiez toujours la même série d'albums de musique Libre pour faire découvrir à vos amis.
- gcp va garder une certaine compatibilité avec les options de cp. Attention cependant, le comportement sera toujours un peu différent (renommage des fichiers par exemple).
Voilà voilà, c'était pour mon besoin perso, mais mon petit doigt me dit que ça servira à d'autres. N'hésitez pas à m'envoyer des retours (notamment sur les performances par rapport à cp, je n'ai pas fait de test poussé, mais ça a l'air de se tenir).
Niveau améliorations, dans celles envisagées il y a:
- modification en temps réel de la queue de copie (pour mettre les fichiers à copier absolument en premier)
- une interface console avancée (probablement sous urwid)
- notifications après une copie un peu longue (via XMPP et peut être mail)
- relancer la copie des fichiers qui ont échoué (vous vous êtes pris les pieds dans le câble usb de votre disque dur)
- correction des nom unicode mal encodés
- vérification de la copie via un hash
dans celles envisageables il y a:
- une interface graphique
- une intégrations aux environnements de bureau (Kde, Gnome, XFCE, ...)
- copie des fichiers à distance (ftp/autre)
- une mode serveur basic pour la copie en réseau quand c'est trop reloud de monter un serveur nfs ou autre
- ... [votre idée ici]
Mais à noter que je ne pourrai pas bosser dessus avant au moins 2 mois.
Et je fini avec un petit lien vers mes autres projets en cours:
-lm (list movies): dont j'ai parlé ici: https://linuxfr.org/~Goffi/29966.html , et qui permet d'afficher vos films à la ls en utilisant les données de IMdB
-SàT (Salut à Toi): mon projet principal, un client XMPP multi-plateforme, multi-frontend, une base pour d'autres idées que j'ai en tête. J'en ai parlé ici: https://linuxfr.org/~Goffi/30073.html et je l'ai présenté ici: https://linuxfr.org/~Goffi/28287.html
et mon blog où vous pouvez suivre et télécharger tout ça: http://www.goffi.org
Journal gcp: un outil de copie à la cp
28
sept.
2010
# Interessant
Posté par shbrol . Évalué à 8.
# Et sinon
Posté par Mr Kapouik (site web personnel) . Évalué à 9.
[^] # Re: Et sinon
Posté par totof2000 . Évalué à 1.
[^] # Re: Et sinon
Posté par El Titi . Évalué à 1.
[^] # Re: Et sinon
Posté par totof2000 . Évalué à -1.
[^] # Re: Et sinon
Posté par Maclag . Évalué à 3.
Qui est avec moi pour le recoder en PHP?
------------------> [ ]
[^] # Re: Et sinon
Posté par skety . Évalué à 3.
[^] # Re: Et sinon
Posté par windu.2b . Évalué à 3.
[^] # Re: Et sinon
Posté par skety . Évalué à 1.
Dire que je me suis relu 3 fois, la honte.
# Dépêche
Posté par Xavier Teyssier (site web personnel) . Évalué à 8.
Tu nous soumets une dépêche ?
[^] # Re: Dépêche
Posté par El Titi . Évalué à 7.
http://linuxfr.org//2010/01/24/26384.html
ca parait être une bonne idée.
Et pour vous mâcher le travail
j'ai «profité» de la perte de ma boîte de vitesse et de me retrouver coincé à Broome (Nord-Ouest de l'Australie... mais ne vous inquiétez pas, je
...
Mais à noter que je ne pourrai pas bosser dessus avant au moins 2 mois.
Et je finis avec un petit lien vers mes autres projets en cours:
-lm (list movies): dont j'ai parlé ici: https://linuxfr.org/~Goffi/29966.html , et ...
Un journal soigné et du bon boulot en tout cas.
Ca serait pas mal de créer une catégorie "coup de coeur" pour les petits projets qui se lancent.
[^] # Re: Dépêche
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Oui une depeche pourquoi pas, jusque qu'en general je prefere attendre que ce soit vraiment utilisable (c'est la raison pour laquelle je n'ai pas encore propose de depeche pour mon projet principal, sat).
enfin dans ce cas, c'est deja utilisable en l'etat, du coup je vais proposer si je trouve un moment.
PS: desole pour les accents, je suis sur un clavier qwerty...
# Python ?
Posté par tesiruna . Évalué à 6.
> détectera l'autre instance et ajoutera ses fichiers à la première copie. Ainsi
> ça évitera à la tête de lecture de vos disques durs de faire des ballades tout
> le temps, et vous pouvez prévoir la fin de la copie plus facilement. Autre
> avantage: vous pouvez commencer une copie, pendant que vous cherchez d'autres
> fichiers à ajouter.
Donc dans le cas où tu fais une copie d'un disque A vers A, et une autre d'un
disque B vers B, le problème que tu soulèves n'a pas lieu d'être, mais il n'y
aura qu'une seule copie à la fois ?
Et puis même, à supposer que je fasse une grosse copie d'un côté, j'aimerais
pouvoir faire une copie d'un petit fichier de l'autre côté sans attendre que la
première prenne fin.
Enfin, est-ce qu'utiliser Python pour gcp ne risque pas d'avoir un impacte
significatif sur les performances ?
Il m'aurait semblé qu'un langage de bas niveau eût été plus indiqué pour ce type
de programme.
D'autant plus que je lis dans les sources que tu récupères le buffer de 4096
bytes dans une chaîne python pour l'écrire dans le fichier cible, et qu'entre
chaque itération tu retourne au watcher glib qui va effectuer à nouveau un appel
à la méthode python. Je pense que ça a un coût non négligeable.
Et sinon, je m'interrogeais :
except KeyboardInterrupt:
raise KeyboardInterrupt
Pourquoi tu captures l'instance d'une exception pour en raiser la classe
équivalente ? :)
[^] # Re: Python ?
Posté par Buf (Mastodon) . Évalué à 3.
[^] # Re: Python ?
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Python ?
Posté par DLFP est mort . Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Python ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Python ?
Posté par DLFP est mort . Évalué à 3.
Donc oui, c'est tout à fait possible d'être CPU bound.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Python ?
Posté par Guillaum (site web personnel) . Évalué à 1.
Sur un fichier de 2 GO, après plusieurs lancements pour être *presque* certain que les deux programmes exploitent de la même façon le cache du système, et en flushant le disque avant/après, bla bla,
En essayant plusieurs taille de *buffer* (ici 16384 Ko), j'obtiens:
time ./test /tmp/big_file /tmp/big_file2 16384
./test /tmp/big_file /tmp/big_file2 16384 0.00s user 1.79s system 14% cpu 12.357 total
time python test.py /tmp/big_file /tmp/big_file3 16384
python test.py /tmp/big_file /tmp/big_file3 16384 0.02s user 2.04s system 21% cpu 9.478 total
Avantage python.
Bon, ce benchmark n'a aucun intérêt, et des fois j'obtiens 11s pour le python et 10 pour le c ;)
C:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv)
{
char* file_in = argv[1];
char* file_out = argv[2];
size_t buffsize = atoi(argv[3]) * 1024;
FILE* fr = fopen(file_in, "rb");
FILE* fw = fopen(file_out, "wb");
char *buffer = (char*) malloc(buffsize);
while(1)
{
size_t read = fread(buffer, sizeof(char), buffsize, fr);
if(read == 0)
break;
size_t writed = 0;
while(writed < read)
{
writed += fwrite(buffer + writed, sizeof(char), read - writed, fw);
}
}
free(buffer);
fclose(fr);
fclose(fw);
}
Python :
import sys
file_in, file_out = sys.argv[1:3]
buffsize = int(sys.argv[3]) * 1024
with open(file_in, 'rb') as fr:
with open(file_out, 'wb') as fw:
while True:
data = fr.read(buffsize)
if len(data) == 0:
break
fw.write(data)
Bon, mon code C pue certainement... Compilé avec -march=native -Os -Wall
Sinon, comment on met du code sans pourrir l'indentation sur linuxfr ?
[^] # Re: Python ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
voir utilise mmap, c'est encore mieux.
"La première sécurité est la liberté"
[^] # Re: Python ?
Posté par Buf (Mastodon) . Évalué à 2.
[^] # Re: Python ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Python ?
Posté par wahnby . Évalué à 1.
avec des nbsp.
ta
ta
tada
[^] # Re: Python ?
Posté par zebra3 . Évalué à 9.
Les vrais hommes programment en assembleur.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Python ?
Posté par nicolas . Évalué à 2.
Il y a 10 types de personnes… :p
[^] # Re: Python ?
Posté par lasher . Évalué à 2.
[^] # Re: Python ?
Posté par Corentin Chary (site web personnel) . Évalué à 4.
[^] # Re: Python ?
Posté par El Titi . Évalué à 3.
Parce que sinon ton optimisation ne marche pas toujours.
[^] # Re: Python ?
Posté par Buf (Mastodon) . Évalué à 2.
- en raid, les données peuvent être sur plusieurs disques
- LVM complique aussi passablement les choses pour savoir sur quel disque on est
- il y a aussi le cas des systèmes de fichiers réseau
- les systèmes montés en loopback
[^] # Re: Python ?
Posté par zebra3 . Évalué à 3.
Par exemple, la commande « # dmsetup deps device » donne les dépendances d'un périphérique, je suppose qu'on doit pouvoir se baser là-dessus.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Python ?
Posté par Spack . Évalué à 2.
[^] # Re: Python ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Or, si tu fais l'essais de copier 2 ou 3 gros fichiers en même temps, le système va sans cesse faire des mouvements de tête de lecture pour passer d'un fichier à l'autre et baisser de beaucoup le débit final.
"La première sécurité est la liberté"
[^] # Re: Python ?
Posté par totof2000 . Évalué à 2.
[^] # Re: Python ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Python ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Donc dans le cas où tu fais une copie d'un disque A vers A, et une autre d'un
disque B vers B, le problème que tu soulèves n'a pas lieu d'être, mais il n'y
aura qu'une seule copie à la fois ?
- oui pour le moment, mais je peux eventuellement faire une option pour desactiver ce comportement (mais c'est a etudier, parce que du coup cq complique pas mal de choses: l'access en concurence aux fichiers de conf, la gestion de la queue a utiliser, etc.
Et puis même, à supposer que je fasse une grosse copie d'un côté, j'aimerais
pouvoir faire une copie d'un petit fichier de l'autre côté sans attendre que la
première prenne fin.
Utilise cp pour ta deuxieme copie ;)
Enfin, est-ce qu'utiliser Python pour gcp ne risque pas d'avoir un impacte
significatif sur les performances ?
j'ai fait des tests tres rapides, ca a l'air de se tenir avec cp, faut faire des tests plus pousses.
apres le troll du langage ma passe loin au dessus de la tete: j'ai fait ca pour mon besoin, et python m'a permis de faire ca tres rapidement.
D'autant plus que je lis dans les sources que tu récupères le buffer de 4096
bytes dans une chaîne python pour l'écrire dans le fichier cible, et qu'entre
chaque itération tu retourne au watcher glib qui va effectuer à nouveau un appel
à la méthode python. Je pense que ça a un coût non négligeable.
il faut retourner a la glib pour gerer les eventuels appels dbus qu il y a eu entre temps, mais le coup devrait etre negligeable. encore une fois il faut tester, et ajuster les valeurs au besoin.
Et sinon, je m'interrogeais :
except KeyboardInterrupt:
raise KeyboardInterrupt
Pourquoi tu captures l'instance d'une exception pour en raiser la classe
équivalente ? :)
parce que sinon elle sera passe sous silence avec le try except, et que je veux qu'elle soit recupere par le try/except de plus haut niveau. si tu as une meilleure solution je suis ouvert, et les patchs/commentaires sont les bienvenus...
[^] # Re: Python ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
significatif sur les performances ?
>> Il m'aurait semblé qu'un langage de bas niveau eût été plus indiqué pour ce type
de programme.
Non, je pense que justement pas.
C'est typiquement le genre d'applis qui n'a PAS besoin d'être codé en C/C++ ou langage de bas niveau.
C'est le genre d'applis que t'écris dans un langage de haut niveau pour gérer tout le tralala (les queues, la distribution, l'historique, etc) et qui au final appelle le cp original.
Il serait idiot, stupide, bête, inepte et con de vouloir utiliser C pour coder ce logiciel. Perte de temps mémorable, et augmentation certaine du nombre de bugs potentiels. Pour un gain plus que négligeable.
[^] # Re: Python ?
Posté par nicolas . Évalué à 4.
Exemple :
nicolas:~% time lookback-time>/dev/null
lookback-time 0,26s user 0,09s system 12% cpu 2,776 total
nicolas:~% time lookback-time>/dev/null
lookback-time 0,22s user 0,02s system 100% cpu 0,247 total
Et après 1 ou 2 minutes :
nicolas:~% time lookback-time>/dev/null
lookback-time > /dev/null 0,21s user 0,07s system 28% cpu 1,009 total
nicolas:~% time lookback-time>/dev/null
lookback-time > /dev/null 0,19s user 0,06s system 93% cpu 0,266 total
[^] # Re: Python ?
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Python ?
Posté par tesiruna . Évalué à 1.
même. Je t'invite à lire mon commentaire attentivement avant de dire des
conneries.
[^] # Re: Python ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Mon point, c'est qu'un outil comme celui là à plus besoin d'être pratique que rapide.
Se dire « oh mon dieux, je dois absolument l'écrire en assembleur pour que les gens le trouvent bien, » c'est con. Si ça amuse certains, tant mieux, hein. Mais c'est un investissement pourri.
[^] # Re: Python ?
Posté par tesiruna . Évalué à 2.
Le monsieur, il ouvre un fp sur le fichier à copier, il ouvre un fp sur le fichier cible, puis il fait des read de 4ko sur le premier pour faire des write sur le second.
Il ne fait donc pas appel à un autre outil, il fait la copie lui même en python.
Est-ce que c'est plus clair ou est-ce que j'ai besoin de te montrer son code pour que tu arrêtes de dire n'importe quoi?
[^] # Re: Python ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Ok donc je vais me répéter parce que tu sembles ne pas me lire.
Et mettre du gras.
>> Le monsieur, il ouvre un fp sur le fichier à copier…
Et alors ?
Je te crois !
Et j'ai même dit que je m'en cognais, car mon commentaire ne parle *PAS* de ça !
Tout ce que j'ai dit, c'est que python/perl/lisp n'est pas un mauvais choix pour ce genre d'appli. Tu *PEUX* faire appel à n'importe quel programme/procédure de bas niveau pour gagner des microsecondes si ça te fait plaisir. Si tu veux utiliser des fp à la main, tant mieux !
Mais pour tout ce qui est autour, la gestion des files, les algos de réplication, la gestion de la ligne de commande, tout ça, le gain en temps de dev, la facilité de compréhension du code, et la clarté du code sont évidents dans un langage de haut-niveau, ce que C n'est pas.
[^] # Re: Python ?
Posté par tesiruna . Évalué à 2.
Donc je te cite, dans ton premier message :
> C'est le genre d'applis que t'écris dans un langage de haut niveau pour gérer tout le tralala (les queues, la distribution, l'historique, etc) et qui au final appelle le cp original.
Donc moi ce que je dis, c'est qu'il n'appelle *PAS* d'outil bas niveau optimisé, il fait la copie lui même en python, c'est à dire qu'à chaque fois il lit 4ko, python va créer un objet str, puis l'écrit dans le fichier cible, puis après rend la main à la glib, qui va faire des trucs dbus, puis va réappeler sa fonction, va relire 4ko, etc. C'est à dire que c'est LENT.
Donc qu'il utilise du python pour tout le cosmetique ne me gêne pas, certaines de mes applications sont en python, ce que je dis simplement, c'est que la copie de fichier est une opération bas niveau, et là il la réimplémente dans un langage haut niveau et interprété.
J'aurais trouvé ça effectivement plus astucieux d'appeler cp ou quelconque outil optimisé pour la copie de fichiers, mais pas de la réimplémenter lui même dans un langage qui n'est pas prévu pour.
[^] # Re: Python ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Ben c'était pas clair.
Tu me parles de fp, moi, ça m'évoque de la prog système, donc pas du haut-niveau.
>> J'aurais trouvé ça effectivement plus astucieux d'appeler cp ou quelconque outil optimisé pour la copie de fichiers,
Envoie un patch !
>> mais pas de la réimplémenter lui même dans un langage qui n'est pas prévu pour.
Bon, ça c'est son problème, plus le notre…
[^] # Re: Python ?
Posté par tesiruna . Évalué à 0.
Tu embrayes sur « envoie un patch », moi je m'en fous je l'utilise pas, je formulais une critique, si tous les habitués de DLFP envoyaient des patches plutôt que de critiquer, Linux serait ready pour le desktop.
Et enfin tu termines par « ça c'est son problème, plus le notre », c'est pourtant le sujet du thread.
[^] # Re: Python ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
J'ai jamais écrit « le programme de machin utilise cp. »
J'ai bien insisté sur le fait que je me tapais complétement des détails d'implémentation, car c'est pas le genre d'application critique qui nécessite une précision au pouillème de microseconde.
Tu montes sur tes grands chevaux : « oh, relis moi, il utilise pas cp. »
Ça tombe mal, car :
J'ai jamais écrit « le programme de machin utilise cp. »
J'ai bien insisté sur le fait que je me tapais complétement des détails d'implémentation, car c'est pas le genre d'application critique qui nécessite une précision au pouillème de microseconde.
>> si tous les habitués de DLFP envoyaient des patches plutôt que de critiquer, Linux serait ready pour le desktop.
Si tous les habitués de DLFP arrêtaient de coder en C, Linux serait ready pour le desktop. Lalala !
>> Et enfin tu termines par « ça c'est son problème, plus le notre », c'est pourtant le sujet du thread.
S'il a fait son journal, il lit les commentaires, il lit des propositions. Il est assez grand.
J'ai pas que ça à foutre non plus. Mon message parlait uniquement du choix d'un langage de haut niveau pour une classe de tâches, mais tu ne m'as pas compris (vu que tu voulais me sortir son code source auquel je ne fais pas référence) et tu me le reproche.
Si tu veux continuer, vas-y, j'en aurai pas plus à fiche.
# TODO list
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Concernant la queue de copie, cela serait top d'avoir une queue par device. Certe, il y a un couplage pas marrant entre la lecture et l'écriture.
Concernant la copie elle-même, cela serait top d'utiliser splice()/vmsplice()/tee() pour faire de la zéro copie (ou mmap ?).
Si tu pouvais faire en sorte que "cp" soit enfin plus rapide que "dd", cela serait super. Les fread/fwrite bufferisent les IO dans un buffer de 64k. Cela fait donc un buffer dans la libc et un buffer dans le noyau (voir 2 avec un read/write classique), soit beaucoup trop de copies.
De plus, 64K est une taille de bloc beaucoup trop fine, même un raptor à une vitesse qui augmente à 1Mo et audela. Sur du raid, le plateau de vitesse est obtenu avec des tailles d'au moins 16 Mo.
"La première sécurité est la liberté"
# coral bay
Posté par cichlid . Évalué à 0.
envoyé depuis mon clavier bépo
[^] # Re: coral bay
Posté par Goffi (site web personnel, Mastodon) . Évalué à 0.
La on est au debut du printemps (enfin a la fin de la saison seche), et c'est limite insuportable de rester dehors tellement il fait chaud...
[^] # Re: coral bay
Posté par llaxe . Évalué à 2.
Alors si les Australiens, en tant que , font pareil, ça pourrait aussi être limite supportable de rester dedans en short+t-shirt </mes excuses pour le HS>
[^] # Re: coral bay
Posté par pasScott pasForstall . Évalué à 3.
J'avais une collegue qui reglait systematiquement la clim de la salle de reunion a 15 degres. A ce niveau la, faut porter une echarpe, une bonnet et des mouffles.
Et se sont effectivement des feles de la clim, toute l'annee je part bosser avec un pull, pour le porter au boulot. En californie du sud, la ou le plus froid que j'ai vu, c'est 7 ou 8 degres l'hiver, le matin quand il fait encore nuit.
Et le pire dans tout ca, c'est qu'autant je comprends que t'utilises la clim en arizona quand il fait 45 a 50 toute l'annee, mais par chez moi, c'est 20 a 25 constamment, avec une fraiche (tres fraiche meme) brise du pacifique.
Sont cons ces ricains...
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: coral bay
Posté par llaxe . Évalué à 3.
Heureusement que quand on revient en France on peut enlever les pulls dans les bureaux en été :-° </ hs>
[^] # Re: coral bay
Posté par pasScott pasForstall . Évalué à 3.
'fin je veux dire, des qui bossent, pas des qui font des courses de chaises a roulettes ou des tournois de poubelle-a-pedale-tennis?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: coral bay
Posté par Frank-N-Furter . Évalué à 4.
Et quand tout le monde rentre, toi tu te casses.
Depending on the time of day, the French go either way.
# rsync
Posté par DLFP est mort . Évalué à 4.
Certaines fonctionnalités sont intéressantes (par exemple la copie vers de la FAT, obligation de pas mal de lecteurs audio portables malheureusement). En revanche, certaines me semblent être redondantes quand on les compare à rsync, qui est déjà une sorte de super cp, avec la même compatibilité des options de base. Pourquoi pas essayer d'utiliser rsync comme backend, ou patcher rsync ? :)
Enfin, pour l'ajout à la liste de copie, comment tu gères le fait qu'on peut avoir plusieurs sources et destinations ? Quand les sources et/ou destinations sont différentes, ce n'est pas forcément intéressant de mettre en queue.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: rsync
Posté par El Titi . Évalué à 3.
Parcher rsync ca nécessite de se mettre au C, de s'impliquer dans un projet qui n'a pas la même vocation (par ex le renommage de fichiers pour éviter l'écrasement n'est pas trivial en utilisant un outil de synchro)
Sinon, faire un backend à un programme qui ne propose pas d'API n'est pas forcément du goût de tout le monde (pas du mien en tout cas)
http://www.mail-archive.com/rsync@lists.samba.org/msg18288.h(...)
[^] # Re: rsync
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Pour info je code aussi en C (j'ai meme deja developpe un pilote sous pour nux, cf mon site), mais je n'ai juste pas le temps ni les ressources (le net surtout !) suffisantes en ce moment pour contribuer a rsync.
En fait bref, ca fait ce que je veux, et je l'ai fait vite.
[^] # Re: rsync
Posté par j_kerviel . Évalué à 4.
Ah la barre de progression effectivement je l'avais déjà vue apparaître sous Gentoo, mais ça a l'air d'avoir disparu. Je n'avais pas imaginé que c'était un patch tierce-partie.Pour avoir une barre de progression, on peut utilise pv : http://www.ivarch.com/programs/pv.shtml
[^] # Re: rsync
Posté par RB . Évalué à 2.
http://chris-lamb.co.uk/2008/01/24/can-you-get-cp-to-give-a-(...)
[^] # Re: rsync
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
# dbus, intelligence
Posté par Damien Thébault . Évalué à 1.
À mon avis, et comme il a déjà été dit, avoir un gestionnaire qui gère de manière intelligente les disques est presque indispensable.
À savoir, que tu peux potentiellement avoir en parallèle 2 copies si 4 disques sont utilisés (potentiellement des disques réseau montés avec gvfs).
Il y a aussi les disques SSD, qui ne se préoccupent pas du mode aléatoire.
[^] # Re: dbus, intelligence
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En fait, en pratique si. Le fait que les secteurs d'effacement des flash fasse 128 ou 256 Ko, cela change pas mal de chose(voir les problèmes de "write amplification").
en pratique, il y a une grosse différence entre accès séquentiel et aléatoire sur un SSD (200Mo/s vs 20Mo/s).
"La première sécurité est la liberté"
# Hors sujet
Posté par Jean Michel (site web personnel) . Évalué à 2.
Comment on peut être à Broome, à 2 heures de Cap Leveque et rester scotcher sur un ordi pour faire un journal sur un sombre outil de copie ... si ça c'est pas du dévouement (limite folie) !
Ça m'en laisse baba :-)
encore toutes mes excuses, vous pouvez reprendre vos débats constructifs
[^] # Re: Hors sujet
Posté par Zarmakuizz (site web personnel) . Évalué à 4.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Hors sujet
Posté par llaxe . Évalué à 8.
Maintenant on comprend pourquoi les africains sont tous des lambins et pourquoi les anglais, dotés d'un temps, il faut bien l'avouer, pourri les 9/10 de l'année, rulent the world. C'est logique.
[^] # Re: Hors sujet
Posté par cichlid . Évalué à 1.
C'est vrai que les Hivers rigoureux finlandais ont largement incité Linus à entendre ce qu'on sait.
Il m'avait pris l'idée courant 2009 de backpacker en australie puis au fil de mes pérégrinations j'avais acheté un eeepc 901 sous xandros (acheté 450$ australiens)
Çe fût vraiment une connerie parce que le degré de geekisme qu'il a ramené m'a fait lâcher mon voyage.
envoyé depuis mon clavier bépo
[^] # Re: Hors sujet
Posté par llaxe . Évalué à 3.
[^] # Re: Hors sujet
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Et de toute facon, je suis venu en australie aussi pour coder (comme ca ca fait un peu bizarre, mais il y a de vraies raisons derriere)... mais ne t'inquiete pas, je ne me suis pas prive de paysage et autre animaux extraordinaires, et surtout de rencontres...
Bref, coder et voyager, c'est pas incompatible ;) (et aussi ecrire, discuter, faire la fete, decouvrir, nager, observer, partir en randonnees).
# zmv
Posté par calandoa . Évalué à 5.
> zmv *.JPEG img/*.jpg
qui va déplacer chacun des fichiers qui se finit par .JPEG et le renommer avec l'extension jpg. Utilisable pour l'instant uniquement par les utilisateurs de zsh, mais peut être qu'il existe un équivalent pour les autres shells?
[^] # Re: zmv
Posté par tesiruna . Évalué à 2.
que le shell les interprète, donc les mettre entre quotes.
[^] # Re: zmv
Posté par KiKouN . Évalué à 1.
[^] # Re: zmv
Posté par zebra3 . Évalué à 4.
Du coup, si rename peut renommer, il peut forcément déplacer, il suffit de lui donner une commande comme "s/^/dir\//".
En écrivant ça, j'ai d'ailleurs eu envie de tester, et ça marche.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.