Par rapport à cp, gcp propose les fonctionnalités suivantes (détails en deuxième partie de dépêche) :
- Une barre de progression ;
- La copie continue en cas d'erreur ;
- Journalisation ;
- Correction des noms de fichiers ;
- Queue unique pour la copie de fichiers ;
- Mémorisation de la liste des fichiers sources ;
- Compatibilité (approximative) avec les options de cp ;
- Disponible en français et anglais.
Enfin, à noter que deux autres projets sont en cours de développement (et disponibles) :
- lm (list movies): un utilitaire en ligne de commande qui affiche la liste de vos films à la ls, mais en utilisant les données de IMDb. Il mentionné ici: http://linuxfr.org/~Goffi/29966.html ;
- SàT (Salut à Toi) : projet principal, un client XMPP multi-plateforme, multi-frontend, servant de bases pour différentes idées/expérimentations. Il a été mentionné ici: http://linuxfr.org/~Goffi/30073.html et mentionné là: http://linuxfr.org/~Goffi/28287.html.
- La barre de progression indique en outre la taille totale des fichiers à copier, le débit et le temps restant estimé ;
- gcp continue la copie même en cas d'erreur : il saute juste le fichier en cause, ce qui vous évitera de devoir recommencer une longue copie juste à cause d'un fichier ;
- 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 étant la copie d'un fichier avec un "?", un "*" ou autre caractère interdit vers un disque en FAT: la copie échouera avec cp tandis que gcp corrigera le nom. Une fonctionnalité particulièrement utile étant donné le nombre de disques durs et autres clés USB/cartes mémoires qui utilisent encore ce système de fichiers archaïque ;
- gcp ne gère qu'une queue de fichiers : si vous lancez une autre copie, gcp détectera l'autre instance et ajoutera ses fichiers à la première copie.
Ceci évitera à la tête de lecture de vos disques durs de faire des ballades en permanence, et vous pourrez prévoir la fin de la copie plus facilement.
Autre avantage : vous pouvez commencer une copie, pendant que vous cherchez d'autres fichiers à ajouter.
À noter que cette fonctionnalité n'est pas - pour le moment - désactivable, ce qui pourrait être souhaitable si vous voulez copier sur deux disques différents en même temps. Des améliorations de ce côté sont envisageables, mais pas certaines, étant donné la complexité que cela implique pour un cas somme toute relativement rare ;
- 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 la faire découvrir à vos amis.
Des outils sont envisagés par la suite pour manipuler ces sauvegardes (les réorganiser, merger, etc.) ;
- 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). gcp n'est *PAS* un remplacement de cp (surtout dans vos scripts !), mais un outil supplémentaire.
Les améliorations envisagées sont :
- 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 noms Unicode mal encodés ;
- Vérification de la copie via un hash ;
- Une interface graphique ;
- Une intégration aux environnements de bureau (KDE, Gnome, XFCE...) ;
- Copie des fichiers à distance (FTP/autre) ;
- Un mode serveur basique pour la copie en réseau quand une solution lourde type nfs est trop compliquée à installer ;
- ... [votre idée ici].
Aller plus loin
- Site (blog) (213 clics)
- billet d'annonce (24 clics)
- téléchargement direct (61 clics)
- billet annonçant Salut à Toi v0.0.3 (6 clics)
- billet annonçant lm (11 clics)
# bonne idée
Posté par François (site web personnel) . Évalué à 5.
Toutefois, et même si gcp ne se veut remplaçant de cp, j'ai *intensément* lutter pour comprendre qu'il était impossible de faire une simple copie de fichier d'un fichier existant vers un nouveau fichier. Voulu ou comportement à corriger ?
En tout cas bonne idée. Plus qu'une interface graphique sur laquelle on peut glisser/déposer ses copies à mettre en queue pour être incontournable !
[^] # Re: bonne idée
Posté par Gui13 (site web personnel) . Évalué à 3.
->
option -f ou --force : force overwriting of existing files
[^] # Re: bonne idée
Posté par François (site web personnel) . Évalué à 4.
Du coup :
jaes:~/gcp$ lsCOPYING fr.po gcp gcp.po i18n README
jaes:~/gcp$ ./gcp fr.po fr.pa
jaes:~/gcp$ ls
COPYING fr.po gcp gcp.po i18n README
ne copie rien (pas plus qu'avec l'option -f).
[^] # Re: bonne idée
Posté par gilgam . Évalué à -4.
COPYING fr.po gcp gcp.po i18n README
jaes:~/gcp$ mv fr.po fr.pa
jaes:~/gcp$ ls
COPYING fr.pa gcp gcp.po i18n README
Non ?
[^] # Re: bonne idée
Posté par Anonyme . Évalué à 2.
password:
root:~> rm -rf ~mounir/tmp /*
NOON !
[^] # Re: bonne idée
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Merci du retour en tout cas, je mettrai un outil de report de bug en ligne des que possible.
PS: le journal se trouve dans ~/.gcp/journal . Il dit quoi ? J'ai prevu d'afficher la liste des fichiers qui ont echoue en fin de copie aussi.
PPS: l'outil graphique avec glisser/deposer arrivera probablement a la fin de l'annee.
[^] # Re: bonne idée
Posté par ercete . Évalué à 1.
ercete@citrouille:~/Developpement/ext/gcp$ ./gcp -f fr.po fr.pa
ercete@citrouille:~/Developpement/ext/gcp$ cat /home/ercete/.gcp/journal
/home/ercete/Developpement/ext/gcp/fr.po
FAILED: can't open dest
[^] # Re: bonne idée
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
pour le moment, gcp prend dest toujours pour un répertoire. Or dans ce cas précis (un fichier copié dans un autre avec un nom différent), ça doit être pris pour un fichier. Du coup il essaye de copier dans blah/fr.pa/fr.po au lieu de blah/fr.pa.
Je corrigerai ça, mais pas avant quelques jours, je ne peux pas avant...
[^] # Re: bonne idée
Posté par LaBienPensanceMaTuer . Évalué à -10.
Peut être tester de façon plus exhaustive avant de tagguer 0.1 et de poster sur linuxfr, non ?
[^] # Re: bonne idée
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
1) c'est justement taggue 0.1 et non 1.0, c'est precise experimental et tout le tralala
2) j'ai poste un journal et on m'a demande de faire une depeche. J'ai meme mis en commentaire que je n'ai pas fait de depeche pour mes autres projets car pas assez utilisables.
3) ce n'est meme pas un bug dans le sens que n'est indique nulle part que gcp gere cette syntaxe (mais il y a d'autres bugs je te l'accorde)
4) j'ai demande a personne d'utiliser mon truc, je l'ai fait pour moi, et je le mets en ligne *au cas ou ca servirait a d'autres*
5) y'a eu des journaux pour des projets de projets (Diaspora au debut), des depeches pour du cinema, ou des trucs ultra-alpha. Si on n'attend que des trucs bullet-proof, y'aura plus grand chose sur linuxfr
6) quand je pense que je viens de perdre 5 min pour repondre a ce commentaire, je comprends pourquoi des fois je passe des nuits sur le net sans rien faire d'utile...
[^] # Re: bonne idée
Posté par Brioche4012 (site web personnel) . Évalué à 8.
Du bon boulot pour une premiere version. On attend la suite avec impatience!
[^] # Re: bonne idée
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
# dépendances = ?
Posté par defmonkey . Évalué à 5.
$ ./gcp
ProgressBar not available, please download it at http://pypi.python.org/pypi/progressbar
Progress bar deactivated
--
Progress bar is not available, deactivating
[...]
Pour les non pythonneux, ça veux dire qu'il va falloir installer du module ...
[^] # Re: dépendances = ?
Posté par ze_lionix (site web personnel) . Évalué à 3.
[apt-get install | yum install ] python-progressbar
Fuse : j'en Use et Abuse !
[^] # Re: dépendances = ?
Posté par François (site web personnel) . Évalué à 1.
# easy_install progressbarDu coup, le script gagnerait peut être à faire partie d'un egg, les problèmes de dépendances seraient pris en charge.
[^] # Re: dépendances = ?
Posté par ze_lionix (site web personnel) . Évalué à 2.
easy_install et un outils/module pour pythonneux qui n'est pas installé de base !
J'ai eu le cas sur un RHEL en voulant installer python-sybase qui l'utilise....
Fuse : j'en Use et Abuse !
[^] # Re: dépendances = ?
Posté par François (site web personnel) . Évalué à 1.
Toutes mes confuses...
Laissons les python egg aux dev python, et les packages au restes du mondes. !
[^] # Re: dépendances = ?
Posté par Stibb . Évalué à 1.
[^] # Re: dépendances = ?
Posté par Brioche4012 (site web personnel) . Évalué à 2.
Si l'utilisateur ne sait pas utiliser son gestionnaire de paquet, c'est d'habitude fort bien documente pour toutes les distributions, laquelle est facilement accessible.
On ne va pas faire de l'assistanat a tout bout de champ que diable, surtout pour une application en ligne de commande.
[^] # Re: dépendances = ?
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# vcp
Posté par barmic . Évalué à 5.
Un truc interessant dans vcp et qui semble ne pas exister dans gcp c'est la possibilité de faire
vcp src dest1 dest2 dest3
Autre chose que j'aime bien dans vcp c'est d'avoir un fichier de configuration. Je pense que c'est une fonctionnalité sympas pour ne pas avoir à remmetre constament les même options et ne pas utiliser un alias non plus. Cela permet aussi de définir des options pour tout les utilisateurs.
D'après ce que montre François, gcp n'affiche rien au final. Je trouve ça dommage. vcp informe sur le nombre de fichier copié, le nombre de fichier qui n'ont pas pu être copié et l'une des fonctionnalité que je souhaitais implémenter était d'indiquer le débit moyens du transfert et le temps total du transfert.
Autre fonctionnalité que je trouverais interessante, le déplacement. réimplémenter la commande mv. Puisque au final ça s'en rapproche. Il faut juste vérifier la les périphériques source et destination pour jouer sur les lien en dur dans les cas où la source et la destination serait sur la même partition. En effet depuis que j'utilise vcp, j'ai tendance à faire des copie de fichier et à supprimer à la main les fichier après à fin de profiter de la barre de progression.
L'utilisation d'un fichier de log est désactivable ? Ce serais bien de pouvoir l'activer uniquement en cas d'erreur et de pouvoir facilement le parser pour effectuer diverses actions directement à partir de ce fichier.
La volonté d'intégration dans les environnement de bureau me fait un peu peur. Personnellement je cherche à ce que l'outil de copie que j'utilise soit le plus léger et le moins dépendant possible.
En tout cas bravo pour ton travail (même si je ne l'ai pas encore testé) et bon courage pour la suite du développement.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: vcp
Posté par blackm . Évalué à 3.
>vcp src dest1 dest2 dest3
Je compare au cp "de base". Si dest3 est un répertoire, la commande est ambigüe (est-elle valide d'ailleurs ?) avec :
vcp src1 src2 src3 dest/
Est-ce que les deux cas sont gérés ?
[^] # Re: vcp
Posté par barmic . Évalué à 2.
Mais ça devrait pouvoir se faire en vérifiant l'existance des fichiers.
Un mode poweruser pourrait être :
cp src1 src2 src3 dest1 dest2 dest3 dest4
Et à partir du premier argument qui est un fichier qui n'existe pas il considère que c'est une destination. Le problème c'est avec les dossiers où il n'est pas possible de savoir si c'est une source (récursive) ou une destination.
Autre possibilité avoir un mot clef :
cp src1 src2 src3 -- dest1 dest2 dest3 dest4
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: vcp
Posté par blackm . Évalué à 1.
Ou, pourquoi pas, faire évoluer l'option -m avec deux syntaxes ?
vcp -m src dest1 dest2 ... (cas déjà traité)
vcp src1 src2 ... srcN -m dest1 dest2 ... destN (cas poweruser)
(La première syntaxe ne serait utile "que" pour la compatabilité.)
[^] # Re: vcp
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
bon sinon pourquoi pas, l'idee est pas mauvaise.
Le debit et le temps total c'est deja indique.
Les erreur en fin de copie, comme dit dans mon autre commentaire, c'est prevu juste pas encore implemente (j'en suis au publish early, maintenant ca va etre du publish often si possible)
[^] # Re: vcp
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: vcp
Posté par Changaco (site web personnel) . Évalué à 1.
[^] # Re: vcp
Posté par Sébastien Wilmet . Évalué à 2.
Euh déplacer un fichier en faisant une copie + supprimer l'original, c'est beaucoup plus lent que de faire un simple mv ! Et si tu dois déplacer un très gros fichier et qu'il ne reste plus assez de place pour faire une copie ?
Je doute très fort que l'implémentation de mv soit un simple cp + rm...
[^] # Re: vcp
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: vcp
Posté par PPmarcel . Évalué à 1.
Le projet de qcp me semble très intéressant aussi, surtout grâce à la gestion d'une queue de transfert.
# En cas d'erreur
Posté par peck (site web personnel) . Évalué à 1.
cp aussi.
[^] # Re: En cas d'erreur
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
# Y'aurait bien un manque : la compatibilité cpold ;)
Posté par Berger Olivier (site web personnel) . Évalué à 2.
http://roland.entierement.nu/blog/2008/01/22/cpold-la-poudre(...)
# coquille...
Posté par ercete . Évalué à 4.
hrrp://www.goffi.org
moi ma maman m'a interdit de parler avec des protocoles inconnus.
Sinon, je teste vite cette version intéressante...
Je rêve déjà d'une interface graphique, voir une intégration pur et simple en lieu et place de la copie de mon nautilus...
oui je rêve, je sais
[^] # Re: coquille...
Posté par Xavier Teyssier (site web personnel) . Évalué à 2.
Et pourtant, déjà 691 clics dessus...
# supercopier-like ?
Posté par nattyebola . Évalué à 1.
Car gnome manque d'un gestionnaire de transfert de fichier nom d'un ptit bonhomme. Ou l'on pourrait : mettre le transfert en pause, réduire la rapidité de transfert, modifier une queue, reprendre un transfert interrompu pour le plus grand bonheur de tous les leecher dans les Lan du monde entier, rien que ca.
Natty ebo
[^] # Re: supercopier-like ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Plus serieusement, tout ca est envisageable (mais encore une fois, ce n'est *pas* mon projet principal, donc ca risque de mettre le temps)
# rahhhh
Posté par Stibb . Évalué à 1.
punaise, pour un outil tel que ça, c'est en C/C++ avec le moins de dépendance possible qu'il faut l'écrire. Voit-on un tar, bzip, cp, scp, rsync, ..., écrit en python qui requiert un gros runtime, des dépendances python à tir la rigaux? non, et c'est pour de bonne raison.
Franchement, y a des claques qui se perdent. Alors, oui, python, c'est super, c'est génial, on code rapidement, c'est à la mode, (c'est aussi terriblement moche, cette histoire d'indentation me sort par les trous du nez, mais bon, ça c'est pour le FUD), mais si l'auteur souhaite que son outil termine utilisé par tout le monde en remplaçant de ce bon vieux cp ou scp, qu'il le réécrive en C ou c++ avec qque dépendances sur des bibliothèques que tout le monde a (libstd, glib, ..) et pis c'est tout!
Quel est donc cette manie de toujours vouloir écrire en langage haut niveau une brique logicielle qui peut s'avérer aussi essentielle... ????
[^] # Re: rahhhh
Posté par barmic . Évalué à 3.
Je ne crois pas qu'il soit envisageable de faire le grand écart entre les deux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: rahhhh
Posté par Naha (site web personnel) . Évalué à 3.
En gros : non, il n'a pas vocation […], et l'auteur s'en fout que ce soit lent, le but était de faire ça vite fait et non de gagner quelques hypothétiques secondes sur le transfert.
[^] # Re: rahhhh
Posté par bilboa . Évalué à 1.
C'est une question d'être léger et tourner partout, une vraie contribution quoi, pas un outil qui sera perdu et oublié aussi vite qu'il à été crée :(
Linux ne tourne pas que sur des desktop ubuntu typiques hein. En fait c'est même pas la majoritée. Et python ca prend de la place et de la ram mine de rien. Bref.
[^] # Re: rahhhh
Posté par Naha (site web personnel) . Évalué à 4.
[^] # Re: rahhhh
Posté par Gniarf . Évalué à 3.
ça doit tourner largement en dessous du megaoctet, et pour la ram bouffée, il faudrait profiler ça mais y'a pas besoin que ça vole haut...
[^] # Re: rahhhh
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: rahhhh
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Ca tombe bien, ce n'est pas le cas (comme explique dans la depeche d'ailleurs.
C'est un outil fait rapidement pour un besoin perso parce que ca faisait longtemps que ces fonctionnalites me manquaient. Maintenant ca repond (a peu pres, sujet a ameliorations) a mon besoin. Si ca sert a d'autre, tant mieux; sinon ben lancez vous dans le votre les gars...
J'ai fait ca vite, ca fonctionne, et ca tient en peu de lignes. Bref, merci python.
PS: je viens de voir que naha a fait exactement la meme reponse que moi =)
PPS: et dans les rapides tests que j'ai fait, c'un peu plus lent que cp, mais ca se tient. A tester plus en profondeur (et optimiser au besoin)
[^] # Re: rahhhh
Posté par Anonyme . Évalué à 5.
Franchement, y a des claques qui se perdent.
Exact, viens ici. :)
[^] # Re: rahhhh
Posté par Sylvain Sauvage . Évalué à 4.
Aïe ! Tirez-lui dessus !
(→ Tire-larigot)
[^] # Re: rahhhh
Posté par El Titi . Évalué à 2.
[^] # Re: rahhhh
Posté par El Titi . Évalué à 10.
Franchement, y a des claques qui se perdent.
Je ne te le fais pas dire.
Le gars, il publie un hack dans un journal pour en faire profiter tout le monde alors qu'il a fait ca pour lui, il utilise ce qu'il connaît, qu'il affectionne et qui va à l'essentiel.
Il donne un peu de son temps pour produire un truc qui marche.
On l'encourage à poster une news parce que ca serait sympa.
Et là évidemment y'a des bozos qui débarquent pour le tâcler en lui disant qu'il faut qu'il refasse tout ça en assembleur parce que voilà Python c'est naze. Et pis faudrait qu'il fasse ca à plein temps et gratos en plus (libre pardon, mais je suis sûr que tu vas te précipiter sur Paypal une fois qu'il a aura tout réécrit) parce qu'un hack comme ca c'est une injure aux utilisateurs rois de DLFP.
Alors oui y'a des claques qui se perdent
Et là, j'ai envie de dire t'as qu'à sortir tes petits doigts boudinés et le faire toi-même le fork en C, le code est en GPL.
# gcp v0.1.1 out
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
- syntaxe gcp FILE FILE_DEST maintenant gérée (cf premiers commentaires)
- erreurs affichées en fin de copie (cf même commentaires)
- mauvaises fermetures des fichiers/du journal en cas de fichier existant corrigée
- erreur lors d'envoi du chemin source via dbus (via une deuxième instance de gcp) corrigée
- et quelques bricoles mineures
Bon maintenant ça vraiment être difficile de bosser dessus dans les semaines à venir, j'espère qu'il n'y a pas de bug majeur... N'hésitez pas à m'envoyer un patch si vous en voyez un ;)
[^] # Re: gcp v0.1.1 out
Posté par djano . Évalué à 6.
Ne te laisse pas démoraliser par les esprits chagrins qui ont loupé tout l'historique de ton logiciel (pourquoi il existe) et de cette dépêche (elle a été créée - ils ont eu raison- alors que tu n'en avais pas spécialement envie).
Bonne continuation!
# progress bar
Posté par Romuald Delavergne . Évalué à 2.
C'est dans l'esprit Unix. Cela s'interface avec n'importe quelle commande.
pv file > dest/file
pv file | nc -w 1 somewhere.com 3000
pv /usr/src/linux-2.6.31.6.tar.bz2 | tar -C /usr/src/ -xjf -
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.