[PROJET]LinCopier - Gestionnaire de copie évolué pour Linux

Bonjour à tous,

je vous copie colle un post que j'ai posté sur le forum d'ubuntu mais pour lequel je n'ai pas encore eu de réponse:

Citation:

---

LinCopier - Gestionnaire de copie pour Linux

Bonjour à tous,

ce matin je suis tombé sur un membre du forum qui cherchait une application équivalente à SuperCopier qui puisse fonctionner sur son Ubuntu.

Un petit tour dans la doc m'a envoyé sur minicopier qui ne semble pas vraiment utilisable et qui se veut de plus multiplateforme et donc écrit en Java. Je ne pense pas que cela soit vraiment une bonne idée de faire un logiciel de ce genre en Java et je ne vois pas l'intérêt de le rendre multiplateforme. SuperCopier fait très bien son travail sur Windows. Et de plus cela ne me semble pas très optimisé.

Je suis aussi tombé sur ultracopier qui à l'air beaucoup plus complet et aboutit cependant, je pense plutôt à quelque chose de plus simple.

En gros, les fonctions seraient les suivantes:

- possibilité de mettre en pause une copie en cours
- possibilité de mettre en file des copies
- possibilité de faire des copies dans les répertoires root (avec évidemment un prompt demandant le mot de passe root et présentant un avertissement des risques encourus --> l'idée m'est venu après avoir constaté plusieurs fois les dégats causé par gksudo nautilus...)
- d'autres fonctions si elles se révèlent vraiment utiles mais le but premier serait de rester sobre et simple

Voilà pour l'idée de l'application qui n'en est... qu'au stade de l'idée pour le moment. Et elle ne tournerait donc que sur les plateformes Linux.

Pour l'instant, il y aurait un ami étudiant en informatique à l'université avec moi et donc moi-même sur le projet. Toute personne désirant s'impliquer dans ce petit projet est aussi la bienvenue!
En effet, j'ai encore beaucoup à apprendre sur le développement logiciel et une aide de quelqu'un d'expérience sera toujours utiles. Et aussi, étant tous les deux étudiants et ayant des programmes chargés, le projet avancera à son rythme.

D'ailleurs, se pose aussi la question du langage et des bibliothèques à utiliser.
Je pensais à python et GTK --> des suggestions de la part de développeurs avancés qui proposerait un autre langage/bibliothèque à utiliser à la place?

Bon, je pose déjà les bases, à voir maintenant si cela pourrait intéresser des personnes.

Au plaisir.

Sherwood51

---

Mes questions principales:
- est-ce que Python vous semble approprié pour un tel projet?
- est-ce que vous pensez que la difficulté du projet est abordable pour de jeunes étudiants motivés mais n'ayant pas forcément beaucoup de temps à consacrer de façon régulière sur un tel projet?

Bref, vos avis d'experts m'intéresse!
Et si quelqu'un aurait envie de rejoindre le projet, cela serait avec plaisir.

Bonjour,

Oui, Python est tout à fait capable de faire ça. Les limites seront à la hauteur de l'ambition du projet et du temps que vous pourrez y consacrer.

J'ai fait pour moi un programme de sauvegarde sélective de répertoires (seulement les fichiers plus récents) avec sélection/exclusions et option miroir (supprime de la destination les fichiers et répertoires qui ont disparu de la source), mais c'était en console et sous Windows. Cependant, j'ai trouvé cela plus complexe que je ne le pensais au départ. Mais c'était d'autant plus intéressant...

Sous linux, je vous conseille de faire un bon cahier des charges qui devra clarifier les limites de votre programme de copie, au moins sur 3 points:

- distinguer une copie d'une sauvegarde. En effet, une sauvegarde est censée copier les fichiers sans les modifier, et les restaurer en place si besoin. Cela pourra changer la manière de traiter, par exemple, la copie des liens symboliques en fonction de l'emplacement visé, ou de savoir s'il faut recopier les metadatas systématiquement. Alors qu'une copie est une "appropriation" des fichiers copiés par l'utilisateur qui copie.

- savoir si vous limitez la copie aux données utilisateurs (répertoires, fichiers "normaux", liens symboliques, éventuellement limité aux points de montage), ou si vous l'étendez à la copie de répertoires système. Dans le second cas, vous aurez à traiter la copie des fichiers spéciaux comme les copies de fichiers de périphériques (dev), les sockets locales et les tubes nommées. Le cas des liens en dur est plus compliqué dans tous les cas, car ce ne sont pas des fichiers, mais des entrées supplémentaires pour accéder aux mêmes données.

- définir les limites dans la prise en compte des droits linux. Bien sûr, on peut se dire: quand je n'ai pas assez de droits, je donne le mot de passe pour les avoir tous. Mais c'est un peu simpliste, et il est dommage de ne pas comprendre un peu plus comment ça marche. Qu'est-ce qu'un utilisateur "normal" a le droit de copier et qu'est-ce qui se passe quand il va au delà?

Vous aurez aussi à résoudre des problèmes d'encodage de noms de fichier.

Bref, c'est a priori un problème plus complexe qu'on ne le pense au départ, mais c'est très intéressant et très formateur.

Sans faire partie de votre équipe projet, je peux au moins vous aider dans 2 domaines:

1- mon programme de sauvegarde sélective n'est pas assez fini pour que je publie, mais il marche, et je le mettrai sans problème à votre disposition. Il contient des fonctions assez robustes et des principes algorithmiques qui fonctionnent bien (copie récursive, effacement récursif, test de sélection/exclusion, p. ex.).

-2 je peux vous aider pour la gestion des droits Linux (hors ACL). J'avais fait une petite étude sur le sujet, elle est ici:

http://linux.jpvweb.com/mesrecetteslinux/droits_linux

Bon courage!

Tyrtamos

[pour Linux, je travaille surtout sur Opensuse, mais je connais aussi Ubuntu et Debian]

Salut,

Citation:

---

Envoyé par Sherwood51

- est-ce que Python vous semble approprié pour un tel projet?

---

Oui, mais Python me semble approprié pour tous les projets (sauf de l'embarqué).
Il faut savoir que Python n'est pas le + rapide des langages, mais les possibilités d'optimisation sont multiples:

• ne pas succomber au syndrome "not invented here", c'est-à-dire se reposer sur des lib déjà écrites si elles remplissent un besoin (et Guido sait qu'il en existe une palanquée !);
• écrire de meilleurs algorithmes (par forcément évident, mais c'est en forgeant... );
• réécrire certaines parties délicates au niveau du temps d'exécution en C.

Je crois (et j'ai eu pas mal de retours qui confirment cette croyance) que la facilité et la rapidité d'écriture d'un programme en Python permettra d'avoir assez vite quelque chose de fonctionnel, qui pourra être optimisé après (même si cela veut dire réécrire une partie (+ ou - grosse) du code en C).

Quoiqu'il en soit, l'optimisation doit être en dernier dans ta liste de priorités.

Make it work, then make it right, then make it fast!

Citation:

---

Envoyé par Sherwood51

- est-ce que vous pensez que la difficulté du projet est abordable pour de jeunes étudiants motivés mais n'ayant pas forcément beaucoup de temps à consacrer de façon régulière sur un tel projet?

---

La majorité (mais je m'avance peut-être, là) des développeurs de logiciels libres gagnent rarement leur vie avec leurs logiciels (et ils ont aussi une vie personnelle). Si vous êtes assez motivés pour aller jusqu'au bout du projet, ça vaut le coup !

Citation:

---

Envoyé par Sherwood51

je ne vois pas l'intérêt de le rendre multiplateforme.

---

Ne soyons donc pas sectaires ! ;)

Citation:

---

Envoyé par Sherwood51

Et elle ne tournerait donc que sur les plateformes Linux.

---

Et non ! Python est assez portable pour que ton programme puisse tourner sur + de plateformes que tu ne l'avais prévu (il faudra juste penser à gérer l'histoire de la copie vers les dossiers root, ça risque d'être rigolo sous Windows !).
En utilisant bien les libs de Python (je pense notamment au module os.path qui permet de ne pas soucier des séparateurs de dossier, de chemin, etc.), le code est normalement exécutable sous Windows et sous Linux sans problème !
Le seul problème qui se posera pour la portabilité sera les éventuels bouts de code C qui auront été créé pour des raisons de perf.
D'ailleurs, je ne sais pas pour GTK, mais Tkinter et wxPython sont portables sur plusieurs plateformes (Tk car il vient avec Python et wx car il est dispo sur une foultitude de plateformes).

Citation:

---

Envoyé par Sherwood51

Je ne pense pas que cela soit vraiment une bonne idée de faire un logiciel de ce genre en Java

---

Et pourquoi pas ? Si le dév a fait du Java pendant des années, qu'il connait bien les libs tierce-partie, qu'il sait optimiser son travail avec Java.
Re-ne soyons donc pas sectaires. ;)

Citation:

---

Envoyé par Sherwood51

qui se veut de plus multiplateforme et donc écrit en Java.

---

Une induction un peu hâtive. Python dispose aussi d'une machine virtuelle, et est donc très portable. La même chose pour Ruby. Et Perl et PHP sont portables aussi.

Citation:

---

Envoyé par Sherwood51

Et de plus cela ne me semble pas très optimisé.

---

D'accord, le logiciel en Java n'est peut-être pas optimisé, mais il ne faut pas croire que Java soit lent.

Bon, vu qu'on n'est pas sur le forum Java, j'arrête là, on risque de croire que je suis un agent infiltré ! :lol:

Si tu connais Python (ou si tu ne connais pas d'autre langage de prog), je te le conseille définitivement, le gain de productivité compense largement les perfs, qui sont de + compensables par les moyens dont j'ai parlé + haut.

Bon courage à vous !

Bonjour,

Citation:

---

Envoyé par nardo47

Et non ! Python est assez portable pour que ton programme puisse tourner sur + de plateformes que tu ne l'avais prévu (il faudra juste penser à gérer l'histoire de la copie vers les dossiers root, ça risque d'être rigolo sous Windows !).
En utilisant bien les libs de Python (je pense notamment au module os.path qui permet de ne pas soucier des séparateurs de dossier, de chemin, etc.), le code est normalement exécutable sous Windows et sous Linux sans problème !
D'ailleurs, je ne sais pas pour GTK, mais Tkinter et wxPython sont portables sur plusieurs plateformes (Tk car il vient avec Python et wx car il est dispo sur une foultitude de plateformes).

---

+1
J'avais fais mumuse il y a un moment avec un gestionnaire de fichier en python/Tkinter et avec os.path et shutil c'est largement portable pour ce qui est des copies/déplacements.
C'est dommage de se priver de cela.

@+

Bonjour,

Juste une petite remarque concernant le caractère multiplateforme (windows/linux/mac): il est inévitable d'avoir des particularités dans la gestion des droits (test avec sys.platform).

C'est plus clair et plus "carré" avec Linux et mac, mais avec Windows (vista et 7), il y a des attributs qui nécessitent un traitement spécifique (attributs caché, système, ...) et certaines règles qui sont mystérieuses et très mal expliquées (certaines actions sont interdites, même sous "administrateur"). Je n'ai pas évoqué ce pb plus haut parce que windows ne faisait pas partie du projet.

A part ces particularités de droits, il est effectivement très facile de faire du multiplateforme.

Pour la bibliothèque graphique, je suggère tkinter. Avec la plupart des linux courants, Python est déjà installé par défaut, et le paquet tkinter est disponible facilement.

Tyrtamos

Bonjour à tous,

tout d'abord, merci pour ces réponses encourageantes!

@tyrtamos: merci beaucoup pour ces précisions et la mise à disposition de ton étude et de ton programme de sauvegarde sélective! :D C'est vraiment encourageant pour nous.

Pour des raisons de complexité, dans un premier temps en tout cas, le programme ne tournera que sur Linux. Ce n'est pas pour être sectaire nardo47 mais pour une question de taille du projet et de complexité. Si le projet avance bien et aboutit à quelque chose de pleinement utilisable, alors pourquoi pas envisager un portage vers d'autres plateformes par la suite mais ce n'est pas un objectif. Quoiqu'il en soit nardo47, merci beaucoup pour ces précieux encouragements, informations et conseils.

Pour la bibliothèque graphique c'est pas vraiment fixé encore. A voir.

On va donc maintenant établir un cahier des charges précis et mon ami devrait pouvoir remettre en ligne son site qui pourra héberger le projet.

Citation:

---

Envoyé par Sherwood51

Pour des raisons de complexité, dans un premier temps en tout cas, le programme ne tournera que sur Linux. Ce n'est pas pour être sectaire nardo47.

---

Ok, la partie "sectaire" était dite avec ironie. Et je vais reformuler mon discours :
Le fait d'utiliser Python te permettra, lorsque le moment sera venu, de porter facilement (disons, moins douloureusement qu'avec d'autres langages qui sont + bas niveau) sur d'autres plate-formes.
(A noter que c'est le cas pour tout langage avec une JVM, donc Java & Ruby... Prolog aussi, maintenant que j'y pense, mais pour faire un copieur en Prolog, faut s'accrocher :D)

PauseKawa a raison de citer shutil, c'est un module fantastique que j'ai découvert récemment, mais que je n'ai pas encore l'habitude d'utiliser (et donc de citer), et qui va t'aider grandement pour ton projet.

Re-bon courage

Citation:

---

Envoyé par nardo47

(A noter que c'est le cas pour tout langage avec une JVM, donc Java & Ruby... Prolog aussi, maintenant que j'y pense, mais pour faire un copieur en Prolog, faut s'accrocher :D)

---

Petite note en passant ;)
JVM signifie Java Virtual Machine, et ne peut donc pas s'appliquer à un autre langage que Java.

Argh ! Damned ! Cela se voit-il donc que j'ai fait du Java avant de passer au Python ? :P

Merci Antoine_935 pour cette judicieuse remarque, je voulais écrire non pas JVM mais VM (ce qui, autant que je me souvienne, ne s'écrit jamais comme ça, d'où mon lapsus digital).

Donc (et pour ceux qui n'en ont rien à carrer de ma vie, et je les comprends, c'est ici que ça commence), Python, Java & Ruby tournent tous avec une machine virtuelle et sont donc hautement portables.

(Voilà, ça apporte pas grand chose au schmilblick, mais je tiens à être précis !)

Bonsoir tout le monde,

Je suis la deuxième personne qui travaille sur le projet de LinCopier :).

Tout d'abord merci beaucoup pour vos réponses^^

Concernant le projet, nous avons un début de site (sur lequel vous trouverez des screenshots de LinCopier, qui n'est encore qu'à ses débuts).

Sans plus attendre, voici le lien ;) -> http://lincopier.gw-computing.net



Bonne soirée à tous,

Revan

Bonjour, je suis le développeur d'ultracopier.
J'aimerai que tu me contacte pour parler d'un rapprochement de nos projets et d'un potentiel partenariat.
Msn/icq/gtalk, ... trouvable sur le site.

En passant 50% du code et 90% des prise de tête vienne du moteur de copie sachant que tu veux les mêmes fonctionnalité qu'ultracopier.

Perso python est bien sur linux, mais sur windows est autre ça fait des applications mal intégré et assez lourde à cause de l'interpréteur python.

Bonjour,

Citation:

---

Envoyé par alpha_one_x86

mais sur windows est autre ça fait des applications mal intégré et assez lourde à cause de l'interpréteur python.

---

Pour diffuser dans le public un logiciel écrit en Python sur Windows, on peut (et même on doit?):

- faire un ensemble autonome "programme + tous ses dll" avec un logiciel comme cx_freeze ou py2exe, pour que le code .py puisse s'exécuter sur n'importe quel PC sans tenir aucun compte d'un éventuel Python déjà installé ni de sa version. Cela permet en plus de ne pas obliger un éventuel client à installer des compléments en plus de Python (bibliothèque graphique autre que TKinter p. ex.). En plus, cx_freeze est multiplateforme, et s'il est bien configuré, c'est le même script setup.py qui permettra de faire la même chose sur Linux.

- créer la version installable avec un produit comme innosetup. Dans ce cas, le fichier .exe s'installe dans le répertoire des programmes comme n'importe quel autre programme Windows, et dispose aussi du mécanisme de désinstallation Windows. Le conversationnel pendant l'installation est bien fait, configurable et multilingue.

De ce fait, le choix de la bibliothèque graphique a moins d'importance, puisque c'est transparent pour l'utilisateur. Et, tant qu'à faire, autant choisir une bibliothèque riche et puissante (PyQt4, PyGtk, wxPython). Une bibliothèque comme PyQt4, par exemple, permet en plus de faciliter la réalisation de logiciels multilingues.

En faisant comme cela, le fait que Python soit interprété n'a pas beaucoup d'importance, et même dispose de l'avantage de la facilité de développement sans l'inconvénient de l'installation du bon interpréteur sur la machine cible. Et sur les PC modernes, Python s'exécute très vite, en particulier parce que le code Python fait très vite appel à des fonctions écrites en C.

Tyrtamos

Salut,

Citation:

---

Envoyé par alpha_one_x86

Perso python est bien sur linux, mais sur windows est autre ça fait des applications mal intégré et assez lourde à cause de l'interpréteur python.

---

:lol:

J'ai pris la liberté de jeter un oeil à votre code.
En fait, il est construit au dessus de Qt - ce qui n'est pas un mauvais choix - et s'il y a facilité d'intégration (du GUI) sur différentes plateformes, on dit d'abord "merci Qt" :mrgreen:

Après ben côté langage de programmation, Qt est plutôt C++ mais il dispose de bibliothèques qui permettent d'utiliser ses fonctionnalités depuis Java et... Python - Yes!!! -

Citation:

---

En passant 50% du code et 90% des prise de tête vienne du moteur de copie sachant que tu veux les mêmes fonctionnalité qu'ultracopier.

---

Effectuer les copies de façon fiable avec une éventuelle limitation de la bande passante utilisée sera effectivement la partie la plus ardue techniquement.
Beaucoup de boulot ayant déjà été fait là dessus, il pourrait être intelligent de le ré-utiliser plutôt que "refaire".

J'ai regardé récemment les possibilités de libcurl/curl, cette réutilisation passe sans doute par "l'intégration" d'une bibliothèque similaire.

C'est ici que Python devient "intéressant": comment articuler l'IHM Qt et les services de libcurl? Ben, on les intègre via PyQt et PyCurl et le code Python fera la glue entre les deux.

Sans ôter à Python ses qualités de langage de programmation, celles ci seront essentiellement utilisées pour "organiser" le boulot qui sera exécuté par les différentes bibliothèques C++ et C utilisées.

Ce sera sans doute un peu plus lent que si vous aviez tout codé vous même en C++ -- une partie du code est interprétée. Mais en ré-utilisant des bibliothèques vous construirez plus rapidement sans sacrifier la robutesse et la fiabilité du code.

- W

Salut à tous,

cela faisait longtemps que je n'étais pas venu voir ce fil.

En fait, finalement le programme est écrit en C et GTK pour le GUI.
Comme on tient à pouvoir optimiser au maximum la fonction de copie, un langage bas niveau s'imposait. Et le C c'est quand même génial :P

Le projet est sur sourceforge --> http://sourceforge.net/projects/lincopier/

Et le dépôt mercurial -->http://lincopier.hg.sourceforge.net:...pier/lincopier

Au fait, j'imagine que du coup le fil devrait être déplacé dans la section appropriée (C) non?