Discussion :

[al1EnC]

Bonjour a tous

Je recherche un appel qui permet une copie de fichier synchrone.

Pour l'instant j'utilise copifile.
Si quelqu'un connait un appel synchrone pour une copie de fichier simple

Merci par avance!

[Grulim]

copifile ??? connait pô...
Si ça vient d'une api système (comme CopyFile sous win32), tu devrais poster dans le forum approprié.
De toute façon, pourquoi veux-tu changer ?

[al1EnC]

Il s'agit bien de copyfile

je dois effectuer des traitements juste apres la copie.
Ces traitements echouent car la copie n'est pas terminée.

Du coup je cherche un appel synchrone permettant de copier des fichiers d'un emplacement vers un autre!

merci par avance pour vos rpéonses!

[loufoque]

T'ouvres le fichier de lecture.
Tu créés le fichier de destination et tu l'ouvres.
Tant que le fichier n'est pas vide
..Tu lis N octets et tu les recopies
Tu fermes le fichier de destination
Tu fermes le fichier de lecture.

[buzzkaido]

Loufoque : c'est sûr, ça marche, mais ça risque d'être sacrement long sur des fichiers un peu important...

CopyFileEx permet de preciser une fonction de callback...

En te servant de ça, tu peux faire attendre ton processus jusqu'a que la fonction de callback le previenne que la copie est finie

https://msdn2.microsoft.com/en-us/library/aa363852.aspx

[Grulim]

Je m'étais jamais rendu compte que CopyFile rendait la main avant d'avoir copiée entièrement le fichier... ça me parait bizarre...
sinon tu as SHFileOperation aussi.

[al1EnC]

merci louffoque mais je crois que je vais choisir la soluce de buzzkaido ... Je vous tiens au courant...

[superspag]

Et bien en lisant l'énoncé du problème... c'est plutôt loufoque qui a raison je trouve S'il te faut explicitement une copie synchrone, pourquoi utiliser une fonction asynchrone pour finalement la rendre synchrone avec une attente ... ?
Surtout que ce n’est pas le code de copie d'un fichier qui va nous demander beaucoup d'effort... Un truc de ce genre ça devrait suffire non ? :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  ifstream iFile("C:/toto");
  ofstream oFile("C:/titi");
  oFile << iFile.rdbuf();
  oFile.close();
  iFile.close();

[loufoque]

Loufoque : c'est sûr, ça marche, mais ça risque d'être sacrement long sur des fichiers un peu important...

Parce que tu crois que y'a un moyen de copier un fichier autrement ?

[buzzkaido]

Ben octet par octet (ou paquet d'octet par paquet d'octet) à un niveau elevé (une boucle en C++ par exemple) ça n'a quand meme pas grand chose à voir avec la même chose à un niveau système.

En gros, en C++ à chaque lecture de paquet d'octet, le système va attendre que le disque se positionne, qu'il qoit prêt, qu'il remplisse un buffer... avant d'envoyer un paquet d'octet en RAM.

A chaque ecriture, pareil.

Avec une opération au niveau du système, toutes ces opérations (qui sont longues par rapport au temps de lecture effectif des données du disque) ne sont faites qu'une fois, en début de boucle.

Et je ne suis même pas sûr que les données transitent par la RAM dans ces cas là.

Essaie de copier octet par octet un fichier de 10Mo et tu verras...


EDIT :

Avec la méthode de superspag, je ne sais pas, je n'ai jamais essayé de coder ça comme un transfert de flux... mais y'a moyen que ce soit une bonne solution intermédiaire.

[loufoque]

En gros, en C++ à chaque lecture de paquet d'octet, le système va attendre que le disque se positionne, qu'il qoit prêt, qu'il remplisse un buffer... avant d'envoyer un paquet d'octet en RAM.

A chaque ecriture, pareil.

Avec une opération au niveau du système, toutes ces opérations (qui sont longues par rapport au temps de lecture effectif des données du disque) ne sont faites qu'une fois, en début de boucle.

Ah ouais, donc le système ne permet plus à d'autres processus de s'executer et d'utiliser le disque ?

Et je ne suis même pas sûr que les données transitent par la RAM dans ces cas là.

Si elles ne transitent pas par la RAM c'est que tu copies octet par octet, et non par paquets d'octets. Ça n'en sera que bien plus lent.