Ultracopier 1.4 est disponible

Ultracopier 1.4 est disponible

Ultracopier 1.4 est disponible

Cela pourra paraître étonnant à certains, mais cet outil existe toujours. Il permet pour rappel d'améliorer les fonctionnalités de copie et de déplacement de fichiers sous Windows mais également Linux. L'application est par exemple disponible sous la forme d'un paquet Debian.

La version macOS est par contre abandonnée. « Mon Mac n’est pas pris en charge par les dernières versions majeures de macOS, et acheter un Mac juste pour cela est trop lourd économiquement. De plus, la base d’utilisateurs sous Mac est inférieure à 1 % » confie le développeur.

Il nous apprend que la nouvelle mouture 1.4 est disponible, avec un code assez largement réécrit et des versions 32/64 bits unifiées. Le support est désormais payant, la gestion du logiciel est désormais « officiellement sous le contrôle de mon entreprise d’hébergement, Confiared », ce qui ne doit rien changer à la philosophie du projet.

Pour la version 2, les performances devraient être largement améliorées, notamment grâce à un nouveau moteur d'évènements natif

Commentaires (25)








Ultracopier 1.4 a écrit :



acheter un Mac juste pour cela est trop lourd économiquement





À cela je lui répondrais qu’il est possible d’utiliser VMware ou VirtualBox pour émuler macOS.



avec win XP, c’était bien pratique (lui ou son homologue dont j’ai oublié le nom)

mais les dernière version de windows ont un gestionnaire de copie certes basique mais pas trop mal

pour ceux qui copient à tour de bras, ça doit être encore assez utile mais si on copie 2 3 fichiers à tout casser, est-ce encore nécessaire ?

(je me pose vraiment la question)


Vraiment ? Je croyais que justement c’était pas possible (interdit par Apple).








Tohrnoriac a écrit :



avec win XP, c’était bien pratique (lui ou son homologue dont j’ai oublié le nom)

(je me pose vraiment la question)





Supercopier peut etre ? Je m’en servais sur XP mais sur W10 plus besoin pour le peu de copies que je fais. Par contre j’imagine que pour plus de copies avec fonctions avancées ca peut etre utile…



Mmmh, pas permis çà.



Où alors acheter un vieux Mac et “réutiliser” sa licence dans une VM est à la limite possible mais pas sûr que celà gère suffisamment de cas de tests.


Mais s’il veut mesurer les performances de la routine de copie, il sera bien obligé de tester sur une machine réelle….


Ah ça me rappelle Supercopier et ceux qui ne juraient que par lui. Paraît-il que la copie était plus rapide, mais je me demandais si ce n’était pas un effet placébo, car l’application doit bien passer par les mêmes routines de l’API Win32 que Windows, donc je ne vois pas bien comment il est possible de grappiller plus que quelques pourcents (et encore)…



Après je ne discute pas des fonctionnalités supplémentaires, car jusqu’à Windows 10, c’était assez pauvre de ce côté-là nativement…


Il lui reste quoi comme fonctionnalités utiles qui ne soient pas dans Windows 10 ?



Je vois qu’on peut limiter la vitesse et chercher dans la liste des fichiers copiés, mais je ne vois pas trop à quoi ça peut servir.








Vekin a écrit :



Paraît-il que la copie était plus rapide, mais je me demandais si ce n’était pas un effet placébo, car l’application doit bien passer par les mêmes routines de l’API Win32 que Windows, donc je ne vois pas bien comment il est possible de grappiller plus que quelques pourcents (et encore)…





Je me suis aussi fait cette remarque. Ce qui limite la vitesse de copie, c’est essentiellement le disque de toutes façons, ou alors c’est très mal programmé, avec des buffers minuscules.







Vekin a écrit :



Après je ne discute pas des fonctionnalités supplémentaires, car jusqu’à Windows 10, c’était assez pauvre de ce côté-là nativement…





Tous OS confondus, j’ai toujours été très étonné que les fonctions de copie soient nativement si peu évoluées, par rapport à par exemple BrowserII sur Amiga au début ou milieu des années 90. Ça ne paraît pourtant pas sorcier.



J’utilise toujours Supercopier 1.2 et ç remplace toujours avantageusement celui de windows.

Remplacement/renommage plus précis que windows

Possibilité d’ajouter des fichiers à la copie/déplacement en ours avec un simple glisser déposer

Possibilité de sauvegarder/restaurer une liste de fichier. (utile quand on doit alelr se coucher et qu’il reste 1To de fichiers à copier !)

Possibilité de Trier la liste des fichiers en cours de copie (par chemin, par taille, par nom. Utile pour faire copier d’abord tous les gros fichiers, puis les petits).

Progression indiquée de manière globale, mais aussi par fichier.



Je n’ai pas réussi à passer a ultracopier  (ou leur supercopier, qui n’est plus le même que la version 1.2) carles fonctionnalités et le comportement est différent








Edtech a écrit :



Il lui reste quoi comme fonctionnalités utiles qui ne soient pas dans Windows 10 ?



Je vois qu’on peut limiter la vitesse et chercher dans la liste des fichiers copiés, mais je ne vois pas trop à quoi ça peut servir.





La mise en file d’attente d’une copie de fichiers lorsqu’une copie est déjà en cours vers un répertoire identique.

Exemple, je transfère un album sur une carte sd qui rame à mort. Si je lance un second transfert alors que le premier n’est pas terminé, Windows va faire tourner les 2 en parallèle.

Ultracopier, lui, va détecter qu’un transfert est déjà en cours pour le même répertoire cible et va simplement le rajouter à  la file d’attente du premier

 



Et le dev continue d’inclure un mineur dans l’installer?








Eradan a écrit :



Et le dev continue d’inclure un mineur dans l’installer?





Source ?



C’est le même développeur (enfin de tête, il a repris le dev de la personne qui s’occupait de supercopier)








Oliewan a écrit :



Vraiment ? Je croyais que justement c’était pas possible (interdit par Apple).





Interdit et impossible sont deux notions différentes.



Je pense qu’il parle de la discution intéressante trouvée dans ce lien

https://bitcointalk.org/index.php?topic=176978.0”>


J’en avais eu un à une époque, mais je ne saurai plus dire de quelle version il s’agissait (c’était bien il y a 5 ans).








wozhdal a écrit :



[…] Je n’ai pas réussi à passer a ultracopier  (ou leur supercopier, qui n’est plus le même que la version 1.2) carles fonctionnalités et le comportement est différent






Pareil, j'utilise toujours SuperCopier2.2ß <img data-src="> (le dernier SuperCopier à l'ancienne avant que cela ne devienne Ultracopier).    



&nbsp;Il me va nickel (sauf pour de rares noms de chemins de répertoire trèèès long).



&nbsp;De win95, à w98, WinXP, Win7, et Win10, je trouve hallucinant que le processus de copie des Windows ne gère pas, de base, des trucs aussi indispensables que, par exemple, la mise en file d’attente …<img data-src=" />



La virtualisation est bien mais ça peut parfois ne pas être suffisant pour le développement d’un outil. L’émulation n’étant pas parfaite, cela peut fonctionner sur machine virtuelle et déconner plein tube sur une vraie machine. C’est pas nouveau. Quelqu’un qui développe en appuyant certaines de ses versions sur des machines virtuelles, c’est n’importe quoi, même si je comprends très bien la contrainte du prix du matos, surtout chez nos potes Apple “plein les fouilles”.

&nbsp;

&nbsp;En fonction des cas, je dois parfois passer par SuperCopier (que je préfère aux autres versions et alternatives) essentiellement lorsque la copie est interrompue (oui même sous 10) à cause d’une erreur.

Il est par exemple très pratique avec les copies depuis des supports contenant des secteurs défectueux, car on lui dit à la première erreur de “passer” et d’appliquer cette directive à chaque erreur du même type, d’autant plus qu’il a une gestion erreurs de lecture plus pratique, ce qui rend la copie plus rapide et même parfois plus fiable dans le sens ou 10 va zapper alors que SuperCopier va réussir.

Il en va de même avec des outils comme 7zip et même Adobe Reader que je préfère 100 fois au système interne de compression et Edge.


Pour ceux qui ne connaitrait pas, j’utilise FastCopy (https://ipmsg.org/tools/fastcopy.html.en). En plus d’être super optimisé pour les opérations de copie/synchro (avec vérification xxHash possible), il est est open source (GPL v3).

Je n’ai pas trouvé plus rapide pour du transfert de petits fichiers (dossiers séquences d’images de plusieurs centaines de Go)








zicklon a écrit :



Je pense qu’il parle de la discution intéressante trouvée dans ce lien

https://bitcointalk.org/index.php?topic=176978.0”&gt;





Et dans celui-ci, que je viens de retrouver. Un grand moment.



Le copieur de fichiers de Windows est bourré de défauts de bout en bout:

Il a une mémoire tampon très petite ce qui pénalise la copie de fichier qui utilise le même disque physique en source comme en destination. Avec une mémoire tampon plus grande, les têtes font moins d’aller-retours et c’est surtout ça qui prend du temps car chaque déplacement coûte une dizaine de millisecondes. Ce défaut concerne essentiellement les disques mécaniques MAIS AUSSI les clefs USB ou cartes mémoire.

Il ne diffère pas les opérations de fichier et accumule les copies, au contraire des gestionnaires de copie qui s’occupent des fichiers les uns après les autres. Encore une fois des tonnes d’aller-retours inutiles de la tête de lecture et des ms de perdues. Concerne toujours les disques mécaniques mais aussi clefs USB, …

Dès qu’il y a une erreur, il s’arrête comme un con, on ne sait pas ce qu’il a fait, ce qu’il restait à faire, etc. Là, on est autant pénialisé qu’on ait du SSD, du HDD ou des cartes mémoires…








raoudoudou a écrit :



Le copieur de fichiers de Windows est bourré de défauts de bout en bout:

Il a une mémoire tampon très petite ce qui pénalise la copie de fichier qui utilise le même disque physique en source comme en destination. Avec une mémoire tampon plus grande, les têtes font moins d’aller-retours





Alors normalement non, car les écritures sont bufferisées sur un OS un peu évolué (ce qui est le cas de XP au moins, a priori).

Sous Linux, sauf à forcer le vidage des tampons/cache (comme la fonction “fsync()” en C ou la commande shell “sync”), les écritures ne sont déclenchées qu’au bout de 5 secondes, et ensuite de manière plus ou moins différées quand on copie un gros fichier.

Donc tu peux avoir un buffer côté programme de 4k, la copie sera déjà très rapide, tu peux essayer. La tête du disque dur ne va pas faire de mouvement pour chaque 4k lu ou écrit par le programme (ce qui limiterait la vitesse de copie à environ 400 k/s pour une tête capable de 100 mouvements par seconde).

Ce qui va ralentir la copie avec des petits buffers, c’est plutôt que ça provoque beaucoup plus d’appels systèmes, et ça a un coût en CPU et en temps.







raoudoudou a écrit :



Dès qu’il y a une erreur, il s’arrête comme un con, on ne sait pas ce qu’il a fait, ce qu’il restait à faire, etc. Là, on est autant pénialisé qu’on ait du SSD, du HDD ou des cartes mémoires…





Pour les autres défauts, je suis d’accord.



Faut croire qu’il y a un flush après chaque fichier copié. Si tu veux copier 1000 fichiers de 4k il va faire un flush tous les 4k au lieu de lire les fichiers jusqu’à remplir son buffer. J’avais écrit un programme à la noix qui chargeait tous les fichiers qu’il pouvait en mémoire avant de les écrire ailleurs et ça avait grave boosté rapport à la copie Windows. Je n’ai pas réitéré sous W10 mais ça devrait pas être long à faire :)


Non pas forcément un flush tous les 4k, ça n’a pas d’intérêt en tous cas.

Sauf si Windows est si mal écrit que la copie le ferait.

Un des coûts important de la copie de 1000 fichiers de 4k est déjà l’ouverture de ces 1000 fichiers, avant même de lire le contenu. Bien sûr, le coût d’ouverture des fichiers destination en écriture est plus important.



Sous Unix/Linux en tous cas, la commande “cp” ou “mv” ne s’amuse pas à provoquer des flush, et il n’y a rien de plus rapide (la limite est celle des disques).


Fermer