Discussion :

[bernards111]

Bonjour,

Existe t il un moyen en python de tester la fin d'une copie d'un fichier afin de pourvoir le déplacer(couper/coller) à nouveau ?

merci d'avance pour les liens ou info qui m'expliquerais ce cas d'usage.

[wiztricks]

Salut,

Ca dépend de qui fait la copie: shutil.copy est synchrone... lorsque l'appel à la fonction revient, la copie est terminée. Mais c'est pas trop compliqué d'emballer çà dans un thread et d'avoir une mouture asynchrone qui ...

- W

[Sve@r]

Bonjour

Existe t il un moyen en python de tester la fin d'une copie d'un fichier afin de pourvoir le déplacer(couper/coller) à nouveau ?

Pas besoin (tout comme dans l'administration, demandez ce que vous voulez et on vous expliquera pourquoi vous n'en avez pas besoin ).
Soit tu coupes/colles depuis Python (ou une IHM écrite en Python ce qui revient au même) et si l'opération ne peut pas se faire parce que ton fichier est en cours d'utilisation ça te remonte une exception que tu peux intercepter (try/except), soit tu coupes/colles depuis autre chose (explorer, gnome, etc) et dans ce cas c'est l'autre chose qui doit gérer l'échec. Dans tous les cas, la copie que tu es en train de faire n'a aucun moyen d'informer l'autre outil qui coupe/colle que le fichier est redevenu disponible. D'autant plus que même si elle pouvait le faire, le fichier pourrait tout de même être recapturé par un 3° acteur entre temps.

Ce n'est pas au niveau de la copie qu'il faut agir, c'est au niveau de l'opération de couper/coller (si cette opération se fait depuis Python évidemment). Dans ce cas il est donc plutôt conseillé de tenter l'opération en présumant que ça pourra se faire tout en veillant quand-même à traiter le cas où ça se passe mal. C'est d'ailleurs une philosophie généralement conseillée pour toute opération plus ou moins critique (EAFP => Easier to ask for forgiveness than permission).

[bernards111]

ok, merci pour vos réponse.

Je ne gère pas la première copie : c'est un script shell.

>>>wiztricks, j'utilise shutil.move pour complétement déplacé le fichier. Ce script python est lancé par le shell. Cela fonctionne pour de très petit fichier mais morcelle le dépôt pour de plus grand. aie

En gros je dois me débrouiller avec seulement le script python .. quel conseils me donneriez vous?

Je ne connais pas le shell mais l'option 'fuser' peut il être utile pour ce problème?

merci de vos conseils.

[wiztricks]

Salut,

En gros je dois me débrouiller avec seulement le script python .. quel conseils me donneriez vous?

Qui fait quoi? qui appelle qui? Si c'est un seul script Python, c'est synchrone...
Si c'est plusieurs scripts on est dans une communication entre processus mais tout cela n'est pas très clair...

- W

[Sve@r]

Je ne gère pas la première copie : c'est un script shell.

Donc tu es sur un unixoïde. Cet OS étant 100% multitâches, il autorise les accès concurrents sur un même fichier. Autrement dit, tu peux tout à fait copier un fichier d'un côté et le déplacer de l'autre. Du côté de la copie, si celle-ci est plus rapide que le déplacement alors elle sera ok sinon tu n'auras qu'une partie du fichier copié. Et le déplacement, lui, se fera dans tous les cas sans se préoccuper de la copie en cours. Et si ce déplacement se fait sur le même fs, alors il se fera par un simple changement de nom donc quasiment instantané. Dans ce cas, autant dire que la copie n'aura aucune chance de gagner la course.

j'utilise shutil.move pour complétement déplacé le fichier. Ce script python est lancé par le shell.

Le même script que celui qui fait la copie ? Si oui alors ça devient facile.

Je ne connais pas le shell mais l'option 'fuser' peut il être utile pour ce problème?

Ce n'est pas une option mais une commande. Et oui si le fichier est utilisé elle affiche le nom du fichier avec le pid du process qui l'utilise et elle retourne 0. Et si le fichier n'est pas utilisé elle affiche juste le nom du fichier sans rien d'autre et retourne 1. Donc oui tu peux utiliser un os.system() et checker son résultat pour prendre une décision.

[bernards111]

Désolé pour le manque de clarté..

Ce sont des utilisateurs qui déposent leurs fichiers sur une serveur , un script Shell est en écoute sur le dossier ou ces utilisateurs font leurs dépôts( différence de type connexion (fibre, adsl ..), et ensuite lorsque qu'un fichier est présent ce Shell lance le script python qui utilise shutil.move. Mais le Shell détecte cette présence de fichier sans attendre la copie entière. Et c'est à ce niveau mon problème lorsqu' il y a gros fichier (2giga par exemple).

[wiztricks]

Salut,

Mais le Shell détecte cette présence de fichier sans attendre la copie entière. Et c'est à ce niveau mon problème lorsqu' il y a gros fichier (2giga par exemple).

Si on regarde la création et le remplissage d'un fichier qui est en train d'être copié, quel seraient les indicateurs à mesurer pour savoir que la copie est bien terminée (alors qu'elle peut juste être suspendue pour être reprise un peu plus tard).

Si on n'a pas plus d'informations (comme par exemple la taille du fichier), on peut s'appuyer sur un protocole (on copie dans un fichier *-copying que l'on renomme lorsque c'est terminé) ou une heuristique (ne pas toucher au fichier tant qu'il n'a pas évolué depuis une poignée plus ou moins généreuse de minutes).

A vous de choisir...

- W

[Sve@r]

et ensuite lorsque qu'un fichier est présent ce Shell lance le script python qui utilise shutil.move. Mais le Shell détecte cette présence de fichier sans attendre la copie entière. Et c'est à ce niveau mon problème lorsqu' il y a gros fichier (2giga par exemple).

C'est là que le bât blesse. Un fichier arrivant dans un dossier ne signifie pas que le fichier est totalement arrivé.

on peut s'appuyer sur un protocole (on copie dans un fichier *-copying que l'on renomme lorsque c'est terminé)

Il ne faut pas oublier que c'est l'utilisateur qui, si j'ai bien compris, dépose directement le fichier via un canal tiers (ex ftp). C'est donc à lui de s'auto contrôler pour déposer le fichier sur un autre dossier intermédiaire puis une fois le fichier arrivé, qu'il le déplace sur le dossier final scruté par le script. Or l'auto-contrôle je n'y crois pas trop.

On peut toutefois envisager un outil de dépot centralisé, point unique d'entrée qui pourrait alors copier le fichier dans un dossier temporaire pour, quand c'est fini, le déplacer dans le dossier final. Déjà ça offrirait une garantie de sécurité supplémentaire (je suis pas fan des utilisateurs qui peuvent arriver sur mon système style "yollo je dépose ce que je veux comme je veux quand je veux").
Ce qui pourrait réduire les intermédiaires. En effet, si ensuite le fichier est de nouveau déplacé par le script Python, on peut alors charger l'outil de dépot de faire le déplacement complet (pourquoi copier dans A pour ensuite déplacer dans B puis lancer un script qui déplacera dans C si on peut immédiatement copier dans C !!!???!!!).

Sinon j'aime bien moi l'idée de fuser (ou lsof qui fait sensiblement le même travail et qui est peut-être plus rapide). Le script shell détectant un fichier donne le bébé au programme Python, programme qui peut alors entamer une boucle d'interrogation toutes les (par exemple) 15 secondes tant que la commande retourne 0. Pour au final enfin pouvoir récupérer le fichier quand celui-ci n'est plus utilisé.

[bernards111]

ok, Ce n'est pas si évident que ça d'autant que je pensais gérer des retours par mail en fonction du type de fichier.....

merci pour ces éléments.

[Sve@r]

Il y a quand-même une question qui me trotte: tu as un script shell qui surveille le dossier, et qui pour tout nouveau fichier délègue le déplacement à un script Python.
Pourquoi Python ? Autant j'aime beaucoup ce langage, autant pour déplacer un fichier je me tournerais quand-même vers un shell. Déjà ce serait plus direct pour fuser ou lsof (pas besoin de passer par os.system()).

[bernards111]

ok, merci pour vos réponse.
Python ne gère pas seulement le déplacement , mais aussi le renommage des fichiers en fonction de l'arborescence des dossiers en écoute par le shell, ainsi que d'autres traitement (renommage, standardisation du contenu ect...)

une heuristique (ne pas toucher au fichier tant qu'il n'a pas évolué depuis une poignée plus ou moins généreuse de minutes).

regarder la taille du fichier (ou du dossier) tous les x minutes et lancer la suite si cette taille n'a pas changer? oui, d'autant que je peux avoir plusieurs fichier et j'aimerais les traiter en lot plutôt que un par un..