En tout cas, merci de te pencher sur le sujet de la copie sur Linux, malgré ton emploi du temps plus que chargé !

@Brunod: toujours notre plus fervent supporter Encore désolé de ne pas avoir de bonnes nouvelles à annoncer...

Disons que c'est un minimum. Les fonctions copy  et copy_dir de copy.c par exemple mériteraient plus d'attention et surtout d'être séparées en plusieurs sous-fonctions.
De plus, mon C s'est largement amélioré depuis le temps où j'avais commencé à écrire LinCopier.

Oui, c'est un fait.

Parfaitement. C'est quelque chose qui doit être pris en compte.

C'est dans mes plans d'ajouter une option pour la vérification de l'intégrité de la copie via empreinte SHA ou MD5.

Merci beaucoup pour tes encouragements ainsi que ton commentaire très intéressant.

EDIT: typo

Cependant, UltraCopier utilise une technique que j'avais utilisée... il y a 25 ans... sur CTOS, un OS désormais éteint.

La technique consiste à faire une copie "en parallèle".

Là, si on regarde comment est faite la copie dans LinCopier, dans le cas général (en ne considérant pas les optimisation fichier <8Mb), c'est avec l'algorithme "naïf" (qui a l'immense mérite d'être simple et donc lisible/maintenable)

Lecture d'un bloc, écriture d'un bloc, lecture d'un bloc, écriture d'un bloc, etc... ,lecture d'un bloc, écriture d'un bloc, lecture dernier bloc, écriture dernier bloc.

L'inconvénient avec cela, si la copie est d'un disque physique à un autre disque physique (local ou réseau) est qu'on perd pas mal de temps à attendre. Supposons en effet qu'il s'agisse de deux disques locaux lisant/écrivant à 80MB/s (valeurs réalistes pour des disques d'âge moyen), eh bien en moyenne la copie d'un fichier de 8GB (100 x 80MB) se fera en 200 sec c'est à dire le temps de lecture + le temps d'écriture puisque rien n'est parallélisé.
Tandis que si on fait 2 threads, un qui lit, un qui écrit et échange de blocs entre les deux (ce que faisait mon programme d'il y a 25 ans...) on se retrouve avec une écriture "en parallèle" et du coup, au lieu de mettre 200 secondes à copier mon fichier de 8GB, on descend à 100 secondes !..

Mais... heureusement pour LinCopier... les O.S. ont évolué depuis le défunt CTOS, et la complexité d'une copie par thread n'est plus totalement nécessaire, du moins sur Linux. En effet, par défaut (sauf option de montage contraire) l'écriture sur un disque est asynchrone. Et donc l'ordre write du C retournera OK avant que les données soient physiquement, réellement écrites sur disque. En fait les données sont juste dans le buffer d'écriture. Si on veut réellement s'assurer que les données sont écrites avant de continuer, il faut "synchroniser". Donc finalement, c'est le buffer d'écriture qui joue le rôle de "thread" et on ne devrait pas trop avoir à s'en soucier sous Linux (et si les options async n'ont pas été explicitement désactivées).

Donc la façon dont la copie est faite (mode naïf avec lecture et écriture alternée) est très probablement le meilleur compromis performance/lisibilité du code sur Linux. Parce que c'est sûr, les threads c'est plus performant (dans le cas de disques physiques différents), mais ça complexifie énormément le code (verrouillages, écritures "dans le désordre", etc...)

Et d'un autre côté, tu évoques la "sécurité des données" en parlant d'UltraCopier... le fait de ne pas "synchroniser" (ou alors j'ai pas vu où c'était dans le code de LinCopier) fait courir un risque à l'utilisateur. En effet, celui-ci peut croire que l'écriture est finie car LinCopier a rendu la main, et il va alors dire "tout va bien, je peux supprimer le fichier source"... il supprime la source, et paf coupure de courant... A ce moment là ce qui était dans le buffer d'écriture est évidemment perdu, et le fichier destination est en réalité partiel.

... bon c'est sûr, je décris un cas "limite"... mais ça finit hélas toujours par arriver.

C'est pourquoi, même avec les outils standards, lorsque j'ai des fichiers auquel je tiens un peu, après une copie, je fais toujours un diff ou un md5 pour vérifier que tout s'est bien passé !

En tout cas, excellent travail, et continuez ainsi.

Pas de news depuis plusieurs mois, donc je viens prendre des nouvelle du projet.
J’espère que le projet n'est pas mort.

@ Rolinh : Merci pour "df3", Apps à découvrir ...
http://linuxfr.org/news/dfc-3-0-0-nouve … taire-df-1

[ /HS LinCopier]

Volontiers si tu souhaites collaborer
Bien évidemment, je suis pleinement disponible pour répondre à toutes les questions que tu aurais sur le code ou autre.
D'ailleurs, une explication de l'architecture serait peut-être nécessaire. De même, utiliser doxygen serait une bonne idée.
Bref, n'hésites pas à me contacter par e-mail.

A+

J'ai un peu de temps et la volonté d'en finir avec ce fonctionnement stupide de Nautilus avec les copies !

Je vais regarder les sources et voir ce que je comprends ou non et je vous poserais sûrement des questions d'ici peu.

A bientôt, Jean-Nono

J'aurais bien mis un encouragement sur le site, mais il faut l'autorisation de l'admin pour activer mon compte...
Allez courage !!!
Bon, moi j'y retourne, je suis encore à 32H51 de copie...

Je l'ai activé. Il faut encore que je prenne un petit peu de temps avant de comprendre comment fonctionne le tout.
Je suppose que tu n'as pas reçu d'email de confirmation? Si jamais c'est normal, j'ai du boulot à faire sur le serveur de mails.