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 Goffi (site web personnel, Mastodon) . En réponse au journal gcp: un outil de copie à la cp. É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...