J'ai des gigas =E0 copier depuis mon disque dur vers un disque
externe connect=E9 en USB. Et avant de copier, je dois v=E9rifier des
trucs pour savoir si je dois vraiment copier ou non.
Pour l'instant, la ligne de mon code python qui copie un r=E9pertoire
o=F9 sans surprise, rep.chemin d=E9signe le chemin du r=E9pertoire local et
rep.distant().chemin d=E9signe le chemin du r=E9pertoire vers lequel il
faut copier.
Pas que ce code ne marche pas, mais disons que le taux de transf=E8re
est inf=E9rieur =E0 2Mo par secondes, alors que je si copie =E0 la souris
dans konqueror (par exemple), j'ai entre 5 et 5 Mo par secondes.
Est-ce que quelqu'un sait comment on peut obtenir des taux de
transf=E8re =E9lev=E9s avec python ?
Un double exemple, qui fonctionne sous windows : import os os.system("xcopy d:source f:destination /i /y") os.system("c:robotcopy.exe d:source f:destination /MIR /FFT /R:2 /W:3")
Notes : - robotcopy est un utilitaire gratuit très intéressant, à télécharger chez MS ; on utilise ici sa fonction de "MOIrroring" - AMHA, la dernière ligne est nettement meilleure
@-salutations
MCI
Bonsoir !
Un double exemple, qui fonctionne sous windows :
import os
os.system("xcopy d:\source f:\destination /i /y")
os.system("c:\robotcopy.exe d:\source f:\destination /MIR /FFT /R:2 /W:3")
Notes :
- robotcopy est un utilitaire gratuit très intéressant, à télécharger chez MS ; on utilise ici sa
fonction de "MOIrroring"
- AMHA, la dernière ligne est nettement meilleure
Un double exemple, qui fonctionne sous windows : import os os.system("xcopy d:source f:destination /i /y") os.system("c:robotcopy.exe d:source f:destination /MIR /FFT /R:2 /W:3")
Notes : - robotcopy est un utilitaire gratuit très intéressant, à télécharger chez MS ; on utilise ici sa fonction de "MOIrroring" - AMHA, la dernière ligne est nettement meilleure
@-salutations
MCI
Méta-MCI \(MVP\)
Bonsoir !
Un double exemple, qui fonctionne sous windows : import os os.system("xcopy d:source f:destination /i /y") os.system("c:robotcopy.exe d:source f:destination /MIR /FFT /R:2 /W:3")
Notes : - robotcopy est un utilitaire gratuit très intéressant, à télécharger chez MS ; on utilise ici sa fonction de "MIRroring" - AMHA, la dernière ligne est nettement meilleure
@-salutations
MCI
Bonsoir !
Un double exemple, qui fonctionne sous windows :
import os
os.system("xcopy d:\source f:\destination /i /y")
os.system("c:\robotcopy.exe d:\source f:\destination /MIR /FFT /R:2 /W:3")
Notes :
- robotcopy est un utilitaire gratuit très intéressant, à télécharger chez MS ; on utilise ici sa
fonction de "MIRroring"
- AMHA, la dernière ligne est nettement meilleure
Un double exemple, qui fonctionne sous windows : import os os.system("xcopy d:source f:destination /i /y") os.system("c:robotcopy.exe d:source f:destination /MIR /FFT /R:2 /W:3")
Notes : - robotcopy est un utilitaire gratuit très intéressant, à télécharger chez MS ; on utilise ici sa fonction de "MIRroring" - AMHA, la dernière ligne est nettement meilleure
@-salutations
MCI
Laurent Claessens
Bonsoir !
Un double exemple, qui fonctionne sous windows : import os os.system("xcopy d:source f:destination /i /y") os.system("c:robotcopy.exe d:source f:destination /MIR /FFT /R: 2 /W:3")
Merci pour la réponse. Hélas elle n'est pas adaptée à mon OS (Linux ); et, chose marrante, la commande Unix cp n'a pas de bon débit non plus. Je me demande quel tour de passe-passe font les konqueror et autres nautilus pour accélérer le débit ...
Laurent
Bonsoir !
Un double exemple, qui fonctionne sous windows :
import os
os.system("xcopy d:\source f:\destination /i /y")
os.system("c:\robotcopy.exe d:\source f:\destination /MIR /FFT /R: 2 /W:3")
Merci pour la réponse. Hélas elle n'est pas adaptée à mon OS (Linux );
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus.
Je me demande quel tour de passe-passe font les konqueror et autres
nautilus pour accélérer le débit ...
Un double exemple, qui fonctionne sous windows : import os os.system("xcopy d:source f:destination /i /y") os.system("c:robotcopy.exe d:source f:destination /MIR /FFT /R: 2 /W:3")
Merci pour la réponse. Hélas elle n'est pas adaptée à mon OS (Linux ); et, chose marrante, la commande Unix cp n'a pas de bon débit non plus. Je me demande quel tour de passe-passe font les konqueror et autres nautilus pour accélérer le débit ...
Laurent
Bertrand B
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus .
Je me demande quel tour de passe-passe font les konqueror et autres nautilus pour accélérer le débit ...
Laurent
Probablement un cache au niveau d'un système de fichier virtuel.
cp sera plus proche de la vérité des temps de transferts vers la clé usb
On peut peut être gagner du temps en créant en local un file system d e la taille de la clé dans un fichier et en utilsant dd pour transférer ce fs sur la clé.
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus .
Je me demande quel tour de passe-passe font les konqueror et autres
nautilus pour accélérer le débit ...
Laurent
Probablement un cache au niveau d'un système de fichier virtuel.
cp sera plus proche de la vérité des temps de transferts vers la clé usb
On peut peut être gagner du temps en créant en local un file system d e
la taille de la clé dans un fichier et en utilsant dd pour transférer ce
fs sur la clé.
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus .
Je me demande quel tour de passe-passe font les konqueror et autres nautilus pour accélérer le débit ...
Laurent
Probablement un cache au niveau d'un système de fichier virtuel.
cp sera plus proche de la vérité des temps de transferts vers la clé usb
On peut peut être gagner du temps en créant en local un file system d e la taille de la clé dans un fichier et en utilsant dd pour transférer ce fs sur la clé.
jean-michel bain-cornu
Bonjour,
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus.
Je me demande quel tour de passe-passe font les konqueror et autres nautilus pour accélérer le débit ...
Probablement un cache au niveau d'un système de fichier virtuel.
cp sera plus proche de la vérité des temps de transferts vers la clé usb
On peut peut être gagner du temps en créant en local un file system de la taille de la clé dans un fichier et en utilsant dd pour transférer ce fs sur la clé.
Je viens de faire un essai (ubuntu v7) en comparant dd (dd if=fichierentree of=fichiersortie), nautilus, et cp . Je ne trouve pas de différence entre nautilus et cp (dans ton cas, nautilus indique-t-il une copie terminée alors qu'elle ne l'est pas en réalité et que le thread de copie tourne encore ?). Je gagne 10% avec dd. C'est peut-être dû à une optimisation au niveau de la taille du cache mémoire utilisé pour la copie (si je ne m'abuse, cp utilise un cache très petit, laissant l'os se débrouiller pour optimiser). On en vient inévitablement à comparer tout ça avec des temps de transferts sous windows, qui sont difficiles à évaluer (le benchmarking, c'est un métier). Quand l'os ne fait que celà, windows semble plus rapide pour les copies de fichiers. Les choses sont moins évidentes quand on essaie de travailler simultanément à la copie, en lançant par exemple une grosse application (n'ayant pas déjà ses dll chargées en mémoire au démarrage du système, genre msoffice...). Il y a aussi le problème de la gestion du format du file system de ta clé. Je suppose que c'est du fat32, et que tu ne peux pas utiliser autre chose ? (genre ext3 ou reiserfs, qui est bien plus efficace dans le cas de la copie d'un très grand nombre de petits fichiers). Si c'est juste une sauvegarde, et que tu n'as pas besoin de compatibilité fat32, tu peux essayer un autre format (il y a des utilitaires pour travailler avec tout ça sous windows, mais alors ce sera windows qui risquera d'être plus lent, of course puisque ce n'est pas le format natif...).
Bref, dis-en un peu plus, et aussi sur les recherches que tu as faites sur internet...
A+ jm
Bonjour,
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus.
Je me demande quel tour de passe-passe font les konqueror et autres
nautilus pour accélérer le débit ...
Probablement un cache au niveau d'un système de fichier virtuel.
cp sera plus proche de la vérité des temps de transferts vers la clé usb
On peut peut être gagner du temps en créant en local un file system de
la taille de la clé dans un fichier et en utilsant dd pour transférer ce
fs sur la clé.
Je viens de faire un essai (ubuntu v7) en comparant dd (dd
if=fichierentree of=fichiersortie), nautilus, et cp .
Je ne trouve pas de différence entre nautilus et cp (dans ton cas,
nautilus indique-t-il une copie terminée alors qu'elle ne l'est pas en
réalité et que le thread de copie tourne encore ?).
Je gagne 10% avec dd. C'est peut-être dû à une optimisation au niveau de
la taille du cache mémoire utilisé pour la copie (si je ne m'abuse, cp
utilise un cache très petit, laissant l'os se débrouiller pour optimiser).
On en vient inévitablement à comparer tout ça avec des temps de
transferts sous windows, qui sont difficiles à évaluer (le benchmarking,
c'est un métier). Quand l'os ne fait que celà, windows semble plus
rapide pour les copies de fichiers. Les choses sont moins évidentes
quand on essaie de travailler simultanément à la copie, en lançant par
exemple une grosse application (n'ayant pas déjà ses dll chargées en
mémoire au démarrage du système, genre msoffice...).
Il y a aussi le problème de la gestion du format du file system de ta
clé. Je suppose que c'est du fat32, et que tu ne peux pas utiliser autre
chose ? (genre ext3 ou reiserfs, qui est bien plus efficace dans le cas
de la copie d'un très grand nombre de petits fichiers). Si c'est juste
une sauvegarde, et que tu n'as pas besoin de compatibilité fat32, tu
peux essayer un autre format (il y a des utilitaires pour travailler
avec tout ça sous windows, mais alors ce sera windows qui risquera
d'être plus lent, of course puisque ce n'est pas le format natif...).
Bref, dis-en un peu plus, et aussi sur les recherches que tu as faites
sur internet...
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus.
Je me demande quel tour de passe-passe font les konqueror et autres nautilus pour accélérer le débit ...
Probablement un cache au niveau d'un système de fichier virtuel.
cp sera plus proche de la vérité des temps de transferts vers la clé usb
On peut peut être gagner du temps en créant en local un file system de la taille de la clé dans un fichier et en utilsant dd pour transférer ce fs sur la clé.
Je viens de faire un essai (ubuntu v7) en comparant dd (dd if=fichierentree of=fichiersortie), nautilus, et cp . Je ne trouve pas de différence entre nautilus et cp (dans ton cas, nautilus indique-t-il une copie terminée alors qu'elle ne l'est pas en réalité et que le thread de copie tourne encore ?). Je gagne 10% avec dd. C'est peut-être dû à une optimisation au niveau de la taille du cache mémoire utilisé pour la copie (si je ne m'abuse, cp utilise un cache très petit, laissant l'os se débrouiller pour optimiser). On en vient inévitablement à comparer tout ça avec des temps de transferts sous windows, qui sont difficiles à évaluer (le benchmarking, c'est un métier). Quand l'os ne fait que celà, windows semble plus rapide pour les copies de fichiers. Les choses sont moins évidentes quand on essaie de travailler simultanément à la copie, en lançant par exemple une grosse application (n'ayant pas déjà ses dll chargées en mémoire au démarrage du système, genre msoffice...). Il y a aussi le problème de la gestion du format du file system de ta clé. Je suppose que c'est du fat32, et que tu ne peux pas utiliser autre chose ? (genre ext3 ou reiserfs, qui est bien plus efficace dans le cas de la copie d'un très grand nombre de petits fichiers). Si c'est juste une sauvegarde, et que tu n'as pas besoin de compatibilité fat32, tu peux essayer un autre format (il y a des utilitaires pour travailler avec tout ça sous windows, mais alors ce sera windows qui risquera d'être plus lent, of course puisque ce n'est pas le format natif...).
Bref, dis-en un peu plus, et aussi sur les recherches que tu as faites sur internet...
A+ jm
Maurice Boucher
Bonjour,
Bertrand B disait le 10/07/07 que :
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus.
Je me demande quel tour de passe-passe font les konqueror et autres nautilus pour accélérer le débit ...
Laurent
Probablement un cache au niveau d'un système de fichier virtuel.
cp sera plus proche de la vérité des temps de transferts vers la clé usb
On peut peut être gagner du temps en créant en local un file system de la taille de la clé dans un fichier et en utilsant dd pour transférer ce fs sur la clé.
Dans /etc/usbmount/usbmount.conf, j'ai supprimé l'option sync. Les transferts sont rapides sur ma clé, ensuite en console je tape la commande sync (à ne pas oublier). J'avais trouvé l'idée sur un forum.
extrait :
8<------8<------8<------8<------8<------8<------8<------8<------8<------ # Filesystem types: USB mass storage devices are only mounted if they # contain a filesystem type which is in this list. ############################################################################# # WARNING! The vfat filesystem does not yet fully implement sync-mounting. # # If you include "vfat" in the list of filesystem types, you *MUST* make # # sure all data is written to the medium before you remove it (e.g. run the # # "sync" command in a terminal window). Otherwise, you *WILL* lose data! # ############################################################################# FILESYSTEMS="ext2 ext3 vfat"
# Mount options: Options passed to the mount command with the -o flag. # WARNING! Removing "sync" from the options is a very bad idea and # might result in severe data loss. #MOUNTOPTIONS="sync,noexec,nodev,noatime,users" MOUNTOPTIONS="noexec,nodev,noatime,users" 8<------8<------8<------8<------8<------8<------8<------8<------8<------
Maurice
Bonjour,
Bertrand B <user@example.net.invalid> disait le 10/07/07 que :
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus.
Je me demande quel tour de passe-passe font les konqueror et autres
nautilus pour accélérer le débit ...
Laurent
Probablement un cache au niveau d'un système de fichier virtuel.
cp sera plus proche de la vérité des temps de transferts vers la clé usb
On peut peut être gagner du temps en créant en local un file system de
la taille de la clé dans un fichier et en utilsant dd pour transférer
ce fs sur la clé.
Dans /etc/usbmount/usbmount.conf, j'ai supprimé l'option sync. Les
transferts sont rapides sur ma clé, ensuite en console je tape la
commande sync (à ne pas oublier). J'avais trouvé l'idée sur un forum.
extrait :
8<------8<------8<------8<------8<------8<------8<------8<------8<------
# Filesystem types: USB mass storage devices are only mounted if they
# contain a filesystem type which is in this list.
#############################################################################
# WARNING! The vfat filesystem does not yet fully implement sync-mounting. #
# If you include "vfat" in the list of filesystem types, you *MUST* make #
# sure all data is written to the medium before you remove it (e.g. run the #
# "sync" command in a terminal window). Otherwise, you *WILL* lose data! #
#############################################################################
FILESYSTEMS="ext2 ext3 vfat"
# Mount options: Options passed to the mount command with the -o flag.
# WARNING! Removing "sync" from the options is a very bad idea and
# might result in severe data loss.
#MOUNTOPTIONS="sync,noexec,nodev,noatime,users"
MOUNTOPTIONS="noexec,nodev,noatime,users"
8<------8<------8<------8<------8<------8<------8<------8<------8<------
et, chose marrante, la commande Unix cp n'a pas de bon débit non plus.
Je me demande quel tour de passe-passe font les konqueror et autres nautilus pour accélérer le débit ...
Laurent
Probablement un cache au niveau d'un système de fichier virtuel.
cp sera plus proche de la vérité des temps de transferts vers la clé usb
On peut peut être gagner du temps en créant en local un file system de la taille de la clé dans un fichier et en utilsant dd pour transférer ce fs sur la clé.
Dans /etc/usbmount/usbmount.conf, j'ai supprimé l'option sync. Les transferts sont rapides sur ma clé, ensuite en console je tape la commande sync (à ne pas oublier). J'avais trouvé l'idée sur un forum.
extrait :
8<------8<------8<------8<------8<------8<------8<------8<------8<------ # Filesystem types: USB mass storage devices are only mounted if they # contain a filesystem type which is in this list. ############################################################################# # WARNING! The vfat filesystem does not yet fully implement sync-mounting. # # If you include "vfat" in the list of filesystem types, you *MUST* make # # sure all data is written to the medium before you remove it (e.g. run the # # "sync" command in a terminal window). Otherwise, you *WILL* lose data! # ############################################################################# FILESYSTEMS="ext2 ext3 vfat"
# Mount options: Options passed to the mount command with the -o flag. # WARNING! Removing "sync" from the options is a very bad idea and # might result in severe data loss. #MOUNTOPTIONS="sync,noexec,nodev,noatime,users" MOUNTOPTIONS="noexec,nodev,noatime,users" 8<------8<------8<------8<------8<------8<------8<------8<------8<------
Maurice
Laurent Claessens
Merci pour les indications. En voici un peu plus.
Il ne s'agit pas d'une clef USB, mais bien d'un disique externe (en flash) de 160 Go, soit le double de mon disque interne (cela empèche la création d'un système local).
J'utilise Ubuntu Feisty. La compatibilité Windows ne me faisant ni chaud ni froid, le disque est formaté en ext3.
Je fais mes test de rapidité avec un fichier iso d'un DVD de 6.4 Go. Je fais mes test comme ceci : je lance la copie et je regarde après une minute combien de mégas ont étés copiés. (pour cela je fais deux $du dans le répertoire vers lequel je copie à 1 minute de distance et je fais la différence; je précise qu'à part le fichier en cours de copie, le répertoire est vide : le temps d'exécution de du lui-même est quasi nul)
Konqueror : 347M (on est d'accord que mon test est imprécis, mais c'est sans appel environ 5 ou 6 fois plus !)
Peut-être que je devrais utiliser la commande de copie de fichier de QT depuis mon programme python. Je suppose que cela est faisable avec tkinter (que je n'ai jamais utilisé) ? Dans ce cas, je ne dois pas me demander comment konqueror fait, ni réinventer la roue : qt se débrouillera pour faire aussi bien que konqueror.
Bonne journée Laurent
Merci pour les indications. En voici un peu plus.
Il ne s'agit pas d'une clef USB, mais bien d'un disique externe (en
flash) de 160 Go, soit le double de mon disque interne (cela empèche
la création d'un système local).
J'utilise Ubuntu Feisty.
La compatibilité Windows ne me faisant ni chaud ni froid, le disque
est formaté en ext3.
Je fais mes test de rapidité avec un fichier iso d'un DVD de 6.4 Go.
Je fais mes test comme ceci : je lance la copie et je regarde après
une minute combien de mégas ont étés copiés. (pour cela je fais deux
$du dans le répertoire vers lequel je copie à 1 minute de distance et
je fais la différence; je précise qu'à part le fichier en cours de
copie, le répertoire est vide : le temps d'exécution de du lui-même
est quasi nul)
Konqueror : 347M (on est d'accord que mon test est imprécis, mais
c'est sans appel environ 5 ou 6 fois plus !)
Peut-être que je devrais utiliser la commande de copie de fichier de
QT depuis mon programme python. Je suppose que cela est faisable avec
tkinter (que je n'ai jamais utilisé) ? Dans ce cas, je ne dois pas me
demander comment konqueror fait, ni réinventer la roue : qt se
débrouillera pour faire aussi bien que konqueror.
Il ne s'agit pas d'une clef USB, mais bien d'un disique externe (en flash) de 160 Go, soit le double de mon disque interne (cela empèche la création d'un système local).
J'utilise Ubuntu Feisty. La compatibilité Windows ne me faisant ni chaud ni froid, le disque est formaté en ext3.
Je fais mes test de rapidité avec un fichier iso d'un DVD de 6.4 Go. Je fais mes test comme ceci : je lance la copie et je regarde après une minute combien de mégas ont étés copiés. (pour cela je fais deux $du dans le répertoire vers lequel je copie à 1 minute de distance et je fais la différence; je précise qu'à part le fichier en cours de copie, le répertoire est vide : le temps d'exécution de du lui-même est quasi nul)
Konqueror : 347M (on est d'accord que mon test est imprécis, mais c'est sans appel environ 5 ou 6 fois plus !)
Peut-être que je devrais utiliser la commande de copie de fichier de QT depuis mon programme python. Je suppose que cela est faisable avec tkinter (que je n'ai jamais utilisé) ? Dans ce cas, je ne dois pas me demander comment konqueror fait, ni réinventer la roue : qt se débrouillera pour faire aussi bien que konqueror.
Bonne journée Laurent
William Dode
On 07-10-2007, Laurent Claessens wrote:
Merci pour les indications. En voici un peu plus.
Il ne s'agit pas d'une clef USB, mais bien d'un disique externe (en flash) de 160 Go, soit le double de mon disque interne (cela empèche la création d'un système local).
J'utilise Ubuntu Feisty. La compatibilité Windows ne me faisant ni chaud ni froid, le disque est formaté en ext3.
Je fais mes test de rapidité avec un fichier iso d'un DVD de 6.4 Go. Je fais mes test comme ceci : je lance la copie et je regarde après une minute combien de mégas ont étés copiés.
Tu ne tiens pas compte du cache dans ce cas. Il faut que tu considère la fin de copie _après démontage du disque_ afin d'être sûr que les données sont réellement écrites. Il faut également le faire deux fois coup sur coup pour que le cache en lecture soit plein.
Il ne s'agit pas d'une clef USB, mais bien d'un disique externe (en
flash) de 160 Go, soit le double de mon disque interne (cela empèche
la création d'un système local).
J'utilise Ubuntu Feisty.
La compatibilité Windows ne me faisant ni chaud ni froid, le disque
est formaté en ext3.
Je fais mes test de rapidité avec un fichier iso d'un DVD de 6.4 Go.
Je fais mes test comme ceci : je lance la copie et je regarde après
une minute combien de mégas ont étés copiés.
Tu ne tiens pas compte du cache dans ce cas. Il faut que tu considère la
fin de copie _après démontage du disque_ afin d'être sûr que les données
sont réellement écrites. Il faut également le faire deux fois coup sur
coup pour que le cache en lecture soit plein.
--
William Dodé - http://flibuste.net
Informaticien indépendant
Il ne s'agit pas d'une clef USB, mais bien d'un disique externe (en flash) de 160 Go, soit le double de mon disque interne (cela empèche la création d'un système local).
J'utilise Ubuntu Feisty. La compatibilité Windows ne me faisant ni chaud ni froid, le disque est formaté en ext3.
Je fais mes test de rapidité avec un fichier iso d'un DVD de 6.4 Go. Je fais mes test comme ceci : je lance la copie et je regarde après une minute combien de mégas ont étés copiés.
Tu ne tiens pas compte du cache dans ce cas. Il faut que tu considère la fin de copie _après démontage du disque_ afin d'être sûr que les données sont réellement écrites. Il faut également le faire deux fois coup sur coup pour que le cache en lecture soit plein.
J'ai des gigas à copier depuis mon disque dur vers un disque externe connecté en USB. Et avant de copier, je dois vérifier des trucs pour savoir si je dois vraiment copier ou non.
Pour l'instant, la ligne de mon code python qui copie un répertoire
où sans surprise, rep.chemin désigne le chemin du répertoire local et rep.distant().chemin désigne le chemin du répertoire vers lequel il faut copier.
Pas que ce code ne marche pas, mais disons que le taux de transfère est inférieur à 2Mo par secondes, alors que je si copie à la souris dans konqueror (par exemple), j'ai entre 5 et 5 Mo par secondes. Est-ce que quelqu'un sait comment on peut obtenir des taux de transfère élevés avec python ?
copytree( src, dst[, symlinks])
Recursively copy an entire directory tree rooted at src. The destination directory, named by dst, must not already exist; it will be created as well as missing parent directories. Permissions and times of directories are copied with copystat(), individual files are copied using copy2(). If symlinks is true, symbolic links in the source tree are represented as symbolic links in the new tree; if false or omitted, the contents of the linked files are copied to the new tree. If exception(s) occur, an Error is raised with a list of reasons.
*************************************************************** The source code for this should be considered an example rather than a tool. ***************************************************************
Changed in version 2.3: Error is raised if any exceptions occur during copying, rather than printing a message.
Changed in version 2.5: Create intermediate directories needed to create dst, rather than raising an error. Copy permissions and times of directories using copystat().
Je t'ai mis entre ******* une partie intéressante :-)
Peut-être reprendre le code, et l'améliorer (taille de buffers)...
Bonjour à toutes et à tous
J'ai des gigas à copier depuis mon disque dur vers un disque
externe connecté en USB. Et avant de copier, je dois vérifier des
trucs pour savoir si je dois vraiment copier ou non.
Pour l'instant, la ligne de mon code python qui copie un répertoire
où sans surprise, rep.chemin désigne le chemin du répertoire local et
rep.distant().chemin désigne le chemin du répertoire vers lequel il
faut copier.
Pas que ce code ne marche pas, mais disons que le taux de transfère
est inférieur à 2Mo par secondes, alors que je si copie à la souris
dans konqueror (par exemple), j'ai entre 5 et 5 Mo par secondes.
Est-ce que quelqu'un sait comment on peut obtenir des taux de
transfère élevés avec python ?
copytree( src, dst[, symlinks])
Recursively copy an entire directory tree rooted at src. The destination
directory, named by dst, must not already exist; it will be created as
well as missing parent directories. Permissions and times of directories
are copied with copystat(), individual files are copied using copy2().
If symlinks is true, symbolic links in the source tree are represented
as symbolic links in the new tree; if false or omitted, the contents of
the linked files are copied to the new tree. If exception(s) occur, an
Error is raised with a list of reasons.
***************************************************************
The source code for this should be considered an example rather than a
tool.
***************************************************************
Changed in version 2.3: Error is raised if any exceptions occur during
copying, rather than printing a message.
Changed in version 2.5: Create intermediate directories needed to create
dst, rather than raising an error. Copy permissions and times of
directories using copystat().
Je t'ai mis entre ******* une partie intéressante :-)
Peut-être reprendre le code, et l'améliorer (taille de buffers)...
J'ai des gigas à copier depuis mon disque dur vers un disque externe connecté en USB. Et avant de copier, je dois vérifier des trucs pour savoir si je dois vraiment copier ou non.
Pour l'instant, la ligne de mon code python qui copie un répertoire
où sans surprise, rep.chemin désigne le chemin du répertoire local et rep.distant().chemin désigne le chemin du répertoire vers lequel il faut copier.
Pas que ce code ne marche pas, mais disons que le taux de transfère est inférieur à 2Mo par secondes, alors que je si copie à la souris dans konqueror (par exemple), j'ai entre 5 et 5 Mo par secondes. Est-ce que quelqu'un sait comment on peut obtenir des taux de transfère élevés avec python ?
copytree( src, dst[, symlinks])
Recursively copy an entire directory tree rooted at src. The destination directory, named by dst, must not already exist; it will be created as well as missing parent directories. Permissions and times of directories are copied with copystat(), individual files are copied using copy2(). If symlinks is true, symbolic links in the source tree are represented as symbolic links in the new tree; if false or omitted, the contents of the linked files are copied to the new tree. If exception(s) occur, an Error is raised with a list of reasons.
*************************************************************** The source code for this should be considered an example rather than a tool. ***************************************************************
Changed in version 2.3: Error is raised if any exceptions occur during copying, rather than printing a message.
Changed in version 2.5: Create intermediate directories needed to create dst, rather than raising an error. Copy permissions and times of directories using copystat().
Je t'ai mis entre ******* une partie intéressante :-)
Peut-être reprendre le code, et l'améliorer (taille de buffers)...
jean-michel bain-cornu
Peut-être reprendre le code, et l'améliorer (taille de buffers)...
Pas sûr que ça change grand chose. Il y a l'OS derrière qui a ses propres buffers...
Peut-être reprendre le code, et l'améliorer (taille de buffers)...
Pas sûr que ça change grand chose. Il y a l'OS derrière qui a ses
propres buffers...