• # Python ?

    Posté par . En réponse au journal gcp: un outil de copie à la cp. Évalué à 6.

    > - 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.

    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 ? :)