Supercopier 3 est sorti. Il s'agit d'un portage vers lazarus afin d'utiliser compilateur et IDE libres. Les versions suivantes sont maintenant disponibles : portable, 32 bits, 64 bits et leur déclinaison en ultimate pour supporter financièrement le projet.
Supercopier est très vieux, il lui manque des contrôles en général (changement des config…), et pendant la copie (le redimensionnement des fichiers n'est pas contrôlé). Le projet va petit à petit se professionnaliser comme l'est Ultracopier.
Plus d'informations dans la suite de la dépêche.
Cette version apporte tout de même son lot de changements :
- gestion native et complète de l'unicode ;
- prise en charge de l'UAC pour windows ;
- améliorations diverses dans le code ;
- amélioration du chargement des DLL d'interception de la copie ;
- amélioration du packaging.
Pour la suite, je pense que le passage sur le protocole et les DLL de cathcopy serait bien. Dans un futur plus lointain, cela va dépendre si la communauté préfère migrer sur Ultracopier ou préfère que le développement de Supercopier continue. Le port pour Linux n'est pas d'actualité pour l'instant (trop gros travail pour faire la même chose qu'Ultracopier). Par contre, j'essaie de prendre en charge correctement Wine.
Dans l'entrée de mon blog je compare Ultracopier à Supercopier. Ultracopier est plus moderne, fait en Qt, a des algos qui permettent de garantir performance/fiabilité sur un maximum d'OS (pas juste un tuning pour tel FS, reste très générique). Dans une machine virtuelle QEMU, copiant depuis et vers un partage réseau Samba un gros fichier, j'ai constaté un gros problème de performance : 1 Mo/s max pour Supercopier et 15 Mo/s moyen pour Ultracopier/Copie normale, l’augmentation du buffer par défaut a diminué le problème. Ultracopier continue à évoluer en même temps que Supercopier (je prépare nouveautés et greffons pour 2013).
Cela va permettre de comparer encore plus les différents copieurs, sur différents OS, les algorithmes, les plateformes, les langages… J'aurai justement besoin de quelqu'un pour m'aider à faire ce grand comparatif pour 2013.
Aller plus loin
- Site officiel et téléchargement de Supercopier 3 (4046 clics)
- Entrée dans le blog de l'auteur (275 clics)
- Page de la version utimate (238 clics)
- Ultracopier (934 clics)
- Comparatif (719 clics)
# Maintenance
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Supercopier et Ultracopier ont l'air d'avoir des objectifs similaires, où trouves-tu donc la motivation de maintenir en parallèle ces deux logiciels ?
[^] # Re: Maintenance
Posté par alpha_one_x86 (site web personnel) . Évalué à 7.
C'est intéressant de pouvoir comparer (platforme, languages, algo). C'est aussi un hommage à Supercopier.
Ca m'as permit aussi de bien regarder le code de Supercopier, pour en prendre les idée intéressantes (au final pas grand chose). Et d'en voir les défauts pour faire mieux.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# J'ai du mal à comprendre
Posté par jben . Évalué à -10.
Dans l'ordre, je vais sur un site web :
puis je choisis une dépèche,
puis je lis :
Faîtes tourner les gens, ça à l'air bien comme substance pour ne pas s'embêter avec ce que certains nomment la cohérence.
[^] # Re: J'ai du mal à comprendre
Posté par alpha_one_x86 (site web personnel) . Évalué à 5. Dernière modification le 23 janvier 2013 à 00:55.
Ultracopier tourne sous linux, et vu que Supercopier est dev en même temps, que les algo sont épluché. Cela profite à tout le monde, linux inclut.
Par contre j'assure le support de wine, ce qui permet d'avoir l'application sous linux/mac, certaine application font ça aussi.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: J'ai du mal à comprendre
Posté par jben . Évalué à 3.
Ça doit être moi qui ait du mal avec le concept. Je n'utilise pas de gestionnaire de fichier, je gère intégralement mes fichiers en ligne de commande, je n'utilise que des trucs comme
mv,cp,rsync…Utiliser un gestionnaire de copie me semble étrange, mais ça c'est mon opinion, et je conçois très bien qu'il peut être utile à certain. Par contre, utiliser un gestionnaire de copie via Wine, je pense que c'est clairement du masochisme.
Par contre l'argument de liberté de Supercopier, et le fait d'étudier le code est pour moi un argument pertinent.
Même si à titre personnel je juge toujours cette dépêche comme inutile, je comprends que certains la trouvent pertinente, c'est un progrès.
[^] # Re: J'ai du mal à comprendre
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Comment peux-tu concevoir qu'il peut être utile à certain et le trouver étrange quand même ?
Ca te semble si étrange qu'on puisse vouloir avoir une contrôle plus fin sur un ensemble de copies de fichier via GUI ? Tu es dans Dolphi/Nautilus, Ctrl-C, Ctrl-V, ça fait apparaître la boite de copie, jusque là ça va ? Les softs "à la Supercopier" se proposent par exemple de mettre les copies de fichier qui ont le même disque dur de destination dans des files d'attente, puisque de toute façon la tête de lecture du HD passe son temps à faire des aller-retour entre les différents secteurs ce qui ralentit tout le monde. Cette file d'attente permet de pouvoir annuler a posteriori certaines copies en particulier, le tout via un GUI également.
[^] # Re: J'ai du mal à comprendre
Posté par barmic . Évalué à 1.
Mais non lui il n'a pas besoin de ça il utilise cp, c'est un cador.
Personnellement c'est le genre de fonctionnalité qui me manque en CLI (je gère aussi mes fichiers en CLI). gcp le propose (ou allait dans ce sens) mais je crois qu'il avait des points qui me gênaient un peu.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'ai du mal à comprendre
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Ultracopier avec une interface ncurse irai?
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: J'ai du mal à comprendre
Posté par barmic . Évalué à 3.
J'allais justement voir s'il y avait quelque chose pour une utilisation CLI.
Je parle ici de mon avis personnel et uniquement personnel.
J'aime pas ncurse. Pour pleins de raisons qui ne sont pas nécessairement objectives.
Par contre un usage en pure CLI avec une icône dans le systray pour le manipuler ce serait top.
À la rigueur 2 commandes une pour lancer des ordres de copie et une pour voir l'interface ncurse (ça se serait cool).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'ai du mal à comprendre
Posté par alpha_one_x86 (site web personnel) . Évalué à 2.
Ca c'est déjà en place. Ca permet de lancé copie/déplacement en CLI. voir ultracopier --help
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: J'ai du mal à comprendre
Posté par barmic . Évalué à 1.
Outch la dernière version fonctionne avec Qt5 ?! Je suis sous Debian Stable moi (et j'ai pas envie de me palucher le backport de Qt5).
J'ai téléchargé la version source de la 3.1.0 ici http://files.first-world.info/ultracopier/0.3.1.0/, mais il n'y a pas d'indication sur comment le compiler dans les README (et il n'y a ni makefile, ni fichiers pour cmake, ni pour les autotools).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'ai du mal à comprendre
Posté par Sylvain Briole (site web personnel) . Évalué à 2.
Je n'ai pas utilisé Ultracopier, mais d'après ce que j'ai lu, Ultracopier avec interface ncurses cela semble correspondre à un sous-ensemble de mc (midnight commander).
[^] # Re: J'ai du mal à comprendre
Posté par barmic . Évalué à 3.
C'est un peu comme si tu disais qu'ultracopier est un sous-ensemble de Dolphin.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'ai du mal à comprendre
Posté par Thomas Debesse (site web personnel) . Évalué à 1.
La fonction copie qu'implémente ultracopier est un sous ensemble de Dolphin…
…tandis que la fonction copie implémentée par Dolphin est un sous-ensemble d'ultracopier ! :)
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: J'ai du mal à comprendre
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Team viewer for linux, c'est une application windows avec un support de wine derrière.
Et je joue sous linux, donc application windows sous linux. C'est lancé une application non conçu pour wine…
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: J'ai du mal à comprendre
Posté par steph1978 . Évalué à 4.
'tain cette question va ressorti à chaque post sur le gestionnaire de copie!!!
c'est pourtant simple:
essaye
et
avec le premier, le disque supportant "qqpart" va voler en éclat.
avec le second, ça passe.
pas besoin de se la péter avec "j'utilise que la ligne de commande, pas le gestionnaire de fichier de madame michou" pour comprendre.
(désolé pour le coup de sang)
[^] # Re: J'ai du mal à comprendre
Posté par jben . Évalué à 3.
Bon alors testons.
Je prépare les données :
Je me prépare un alias, car je vais vider les caches pour chaque essai afin d'être dans des conditions équivalentes.
Voici mes 4 commandes de test :
séquentielle
avec sync final
rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 1 cp -r; sync"sans sync final
rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 1 cp -r"parallèle
avec sync final
rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 2 cp -r; sync"sans sync final
rm -rf qqpart/*; sync; res; time sh -c "echo qqch1/ qqpart/ qqch2/ qqpart/ | xargs -n 2 -P 2 cp -r"Bilan :
Bref, dans mon cas c'est le noyal qui s'occupe de bien faire comme il faut. Oui, les valeurs de
dirty_ratio,dirty_expire_centisec,dirty_background_ratio… ne sont pas celles par défaut. Ce sont celles qui correspondent à mon usage.[^] # Re: J'ai du mal à comprendre
Posté par steph1978 . Évalué à 5.
Je me serai attendu à un petit delta dans les résultats.
Cela dit, 100 fichiers de 10M est un cas très particulier pour lequel tu bénéficies beaucoup du séquentiel.
D'autre part ils ont été créés d'un coup donc sont à la suite sur le disque.
Ensuite, 10Mo, ça tient en cache.
Donc, grossièrement, pour le cas en parallèle, le disque fait:
- lit en zone 1
- seek zone 3
- ecrit en zone 3
- seek zone 2
- lit en zone 2
- seek zone 3
- ecrit en zone 3
- seek zone 1
- loop
Et, comme le noyau optimise les écritures, on peut même penser que les écritures en zone 3 sont groupées, économisant un seek.
Bref, il faut essayer des cas plus concrets avec des arborescences plus grandes et des fichiers plus petits.
[^] # Re: J'ai du mal à comprendre
Posté par jben . Évalué à 1.
En fait, l'écriture se fait à la fin en grande partie, lors du sync. Les écritures sont toutes bufferisés. C'est sur la lecture qu'il y a une optimisation possible, mais un bon choix du readahead résoud ce problème.
Donc tu veux des plus petits fichiers, ok. Je vais aussi me mettre en condition plus violentes, 4 cp séquentiels contre 4 cp parallèles. Donc 4 dossiers contenants chacun 100 MiB en fichier de 10 KiB.
La commande de test sera pour le séquentiel :
Et pour le parrallèle :
Et alors là les performances sont même contraire à que vous suggerez :
Je le répète, pour moi, c'est le rôle du noyau d'optimiser ce genre de chose, pas de l'utilisateur. Encore faut-il avoir une machine bien configuré, et assez de RAM relativement à la taille des données qu'on manipule. C'est vrai, sur une machine limitée en mémoire, le noyau ne peut pas optimiser car il ne peut pas garder assez de pages sales en mémoire, mais ce n'est pas le cas général.
Pour moi le raisonnement est simple, je configure bien mon système par rapport à mon usage, je lui donne les moyens adéquats (assez de mémoire), et après c'est son problème, pas le mien. Toutes ces solutions (mise en file pour une copie séquentielles, etc.) ne sont à mes yeux que des solutions de contournement, et elle ne sont donc d'aucunes utilité quand il y a rien à contourner.
[^] # Re: J'ai du mal à comprendre
Posté par jben . Évalué à 1.
Et je me répond à moi-même, pour préciser que dans le cas où les données à copier sont en cache, on observe des résultats similaires :
Pour le séquentiel :
Pour le parallèle :
On obtient 9.4 s pour le séquentiel et 8.2 s pour le parallèle.
Bref, je ne vois pas quoi faire d'autre pour argumenter mon propos. Mais si vous me sugerez d'autres tests, je les ferais avec plaisir.
[^] # Re: J'ai du mal à comprendre
Posté par alpha_one_x86 (site web personnel) . Évalué à 4. Dernière modification le 24 janvier 2013 à 17:13.
Je tiens à préciser quelque chose:
Dans l'ensemble, quand ont reste dans le cache/buffer, tout les systémes ont à peu prêt les mêmes caractéristiques.
Par contre, quand le buffer/cache est trop petit, la, la différence coté application ET coté OS se fait (réorganisation des accès hdd).
Et la, une simple boucle read/write comme dans Supercopier se fait défoncé coté performance, surtout avec la taille des bloques à 4Ko. Car si les block font 4Ko, ça veux dire que vu que l'application fait une boucle, cela force l'OS à faire 4Ko de lecture, puis 4Ko d'écriture, et donc à bouger la tête de lecture tout les 4Ko.
Attaquer les ouvertures de fichiers en parallèle, permet d'attaquer la liste des inodes dans un dossier, et ça laisse l'OS grouper plusieurs lectures.
Mais la plus grosse différence entre chaque logiciel de copie, c'est bien quand le FS est sensible au latence. Par exemple attaquer un partage smb1 avec samba 3.6, et garder de bonne performance (surtout depuis windows, même le 7), demande pas mal de compétence.
Pour plus d'info, j'ai documenté tout ça dans mon wiki d'ultracopier.
Pour info, Qt fait un sync à chaque close() de chaque fichier. Garder de bonne performance dans ces conditions, c'est pas facile.
J'ai mit ça en évidence rapidement dans: http://ultracopier.first-world.info/articles/security-speed-ultracopier-supercopier-teracopy-copyhandler.html
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: J'ai du mal à comprendre
Posté par jben . Évalué à 2.
Donc en gros, tu es d'accord avec moi, si on a un cache et des buffers configurés de tel sorte qu'ils soient suffisamment gros (donc avec de la RAM en face), l'utilisation d'un gestionnaire de copie est inutile. Sans vouloir dénigrer les gestionnaires de copies, ça reste du rustinage pour les systèmes matériellement limités où le noyau ne peut pas faire bien son boulot.
Je te rejoins complètement sur cette critique, mais pour des raisons radicalement différentes. Toi tu fais un boulot qui devrait normalement être effectué par le noyau et ce comportement te gène. De mon coté, bien que je pense qu'il est normal que depuis l'espace utilisateur on puisse demander un sync pour vider écrire les pages sales, cela reste un besoin extrêmement spécifique, et à mon avis les programmes ne devraient pas, sauf exceptions, interférer avec la politique d'écriture du noyau.
Par exemple sur mon notebook, j'ai une politique extrêmement agressive de gestion de l'énergie, en particulier j'ai une expiration des pages sales de 30 minutes. Je sais ce que je fais, c'est mon choix, ça correspond à mon usage. Je ne veux pas que les programmes s'occupe du boulot du noyau, c'est le boulot du noyau, j'ai configuré ce qu'il faut pour, les programmes : laissez faire le noyau.
[^] # Re: J'ai du mal à comprendre
Posté par alpha_one_x86 (site web personnel) . Évalué à 4.
Oui, un gestionnaire de copie est inutile coté performance si l'OS fait bien sont boulot. Hors dés fois c'est pas possible, car le protocole distant est mal foutu, car il y as des latences (sur internet des fois). Bref, le cas parfait n’existe pas. Et pour les gros copieurs, ont utilise HDD/SDD, pas de rame disque, car le volume manipulé est toujours supérieur à la mémoire.
Par contre c'est QUE le 3eme point de mon logiciel (tout le monde ne jure que par les performances). 1er point c'est la fiabilité de la copie (peu de personne prenne en compte ce point jusqu’à ce qu'il perdent leur données). 2eme point c'est les fonctionnalités (gestion de la liste de copie, pas forcément pour les performances, limitation de la vitesse, gestion des collisions/erreurs, plus d'info, …)
Oui, laisse la possibilité de faire une chose, ça ne veux pas dire qu'elle doit être fait systématiquement. Et inversement: une chose fait occasionnellement, il faut laisser un moyen de le faire, car quand il y en as besoin… (Qt ne permet pas d'écrire les dates des fichiers par exemple).
Moi j'aimerai bien un moyen de désactivé la possibilité de faire un sync sous linux (pas la commande, mais l'appelle système). Car dans un env KDE, 95% des applications font un sync à chaque close, et en plus certaine application ferme et ouvre des fichiers sans arrêt.
Mais pour l'instant je considère que Linux à une gestion passable du HDD, surtout car le swap, ou swap + accès à plusieurs FS est très merdique. J'ai un SSD pour mon OS, je me tape encore des bon gros coup de lag (pas de tuning noyau, je considère qu'un utilisateur ne doit pas tunner sont noyau sauf cas particulier, hors l'utilisation desktop est très courante).
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: J'ai du mal à comprendre
Posté par jben . Évalué à 1. Dernière modification le 24 janvier 2013 à 18:42.
Moi je ne considère pas un disque comme fiable. Je dois être parano. Donc pour moi, écrire de manière fiable sur un support qu'il ne l'est pas, ce n'est pas très utile. Pour cela j'utilise d'autres solutions pour garantir la pérennité de mes données (comme des sauvegardes délocalisées)
Il existe une lib chargeable en
LIB_LD_PRELOADpour cela. Ils fournissent même un wrapper pour ne pas avoir à faire le preload à la main. C'est libeatmydata.C'est à utiliser en connaissance de cause bien sûr.
[^] # Re: J'ai du mal à comprendre
Posté par alpha_one_x86 (site web personnel) . Évalué à 4.
Idem, j'ai un backup sur un autre HDD.
Mais justement, quand tu copie sur un hdd, ou même sur ton backup, et que la copie est corrompu… et que tu t'en aperçois que quand tu en as besoin…
Cas que j'ai déjà eu: déplacement de C:\ vers partage réseau sous windows, le cable réseau est déco, et windows supprime en boucle tout les fichiers sources (comme si il été déplacé). Et donc je me retrouve avec un perte de donnée.
Ou un gas qui part car je lui est remplit sont hdd de
pornfilm, il arrive chez lui est voie que la copie n'as pas été faite correctement…Ne pas pouvoir te fier au media c'est normal, ne pas pourvoir de fichier à la partie logiciel (OS, FS, gestionnaire de copie), c'est pas normal. Si tu croi le contraire, tu doit être le seul. Combien de gens ont gueler au bug noyau qui détruisais les données des partions ext4.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: J'ai du mal à comprendre
Posté par jben . Évalué à 1.
J'ai du mal à comprendre en quoi la fiabilité est meilleure. Quand j'ai besoin de copier des données en local sur un média, j'y vais à coup de
cp,sync, démontage. Dès que c'est à distance,rsyncest mon seul ami.De toutes les façons vu le peu de copies local de fichier que j'effectue, genre en local pour mes fichiers j'utilise un gestionnaire de version, ça me suffit.
Bref, à part le point interface et convivialité du bestiaux qui ne m'interesse pas (mais ça c'est mon coté refractaire, c'était mieux à vents), je n'arrive toujours pas à voir pourquoi un gestionnaire de copie pourrait m'être utile.
[^] # Re: J'ai du mal à comprendre
Posté par barmic . Évalué à 3.
Et tu ne vérifie pas que la copie de ta sauvegarde c'est bien faite ? Si c'est le cas c'est dommage.
Mais ce qui est vraiment dommage c'est de te voir depuis 2 jours aligner les "moi je …" tune mon noyau, n'est pas besoin de… etc en prenant un peu tout le monde de haut.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'ai du mal à comprendre
Posté par jben . Évalué à 2.
Si bien sûr, avec l'outil de transfert, une vérification périodique des checksum est effectuée.
Au lieu d'utiliser ce genre d'arguments, je sais que la forme de mon discours est perfectible, pourrais-tu répondre sur le fond ? Je parle de ce qui doit être fait par le noyau et fait par les programmes en espace utilisateur ? J'ai une opinion, je l'exprime comme étant la mienne sans généraliser, il est vrai que je pourrais l'exprimer différement.
Et ce n'est pas tuner son noyau de choisir des valeurs adaptées à son usage. D'ailleurs des programmes permettent très facilement de régler ce genre de chose, par exemple
laptop-mode-tools.[^] # Re: J'ai du mal à comprendre
Posté par barmic . Évalué à 4.
Ça ne fait pas de mal que ton outil de copie le fasse. Personnellement une fois j'ai un peu à la va vite fait une copie d'un gros fichier sur une clef avant de partir pour me rendre compte pendant mon voyage (quand j'en avais besoin) que la copie c'était mal passé. C'est pas agréable.
D'ailleurs (je sais pas sur quoi tu fais tes backups) mais btrfs et zfs font eux aussi des checksum sur les (meta ?)données et au moins pour btrfs, il est capable de corriger les erreurs si le volume en question est en RAID autre que 0. Ce n'est pas parce que ta couche en dessous n'est pas fiable que tu ne peut pas par dessus ajouter de la fiabilité (comme en réseau) et c'est très agréable quand ton origine ou ta destination ne sont pas des périphériques branchés en IDE/SATA/SCSI.
Bref ça peut être utile.
Comprends que c'est lié et quand tu rentre dans le lard de ton interlocuteur ça a plus tendance à le braquer.
Et c'est très bien ! (vraiment je parlais de la forme et pas du fond)
Tu n'a peut être pas tendance à généraliser mais tu donne vraiment l'impression de rabaisser les autres. Notamment dès le départ quand tu les met dans une jolie boite : ceux qui utilisent des gestionnaires de fichiers alors que toi tu fais de la CLI (alors que vcp et gcp entre autre montre que ce besoin est exprimé aussi par des utilisateurs de CLI).
Si c'est tuner son noyau, mais il n'y a aucun mal si je connaissais cette technique je l'aurais probablement fais. Je n'ai absolument rien contre.
Par contre j'ai des questions sur ta technique.
Tu augmente la quantité de pages sales que le noyau accepte. Ça reviens à augmenter le buffer de lecture (comme tu l'a bien dis les écritures sont asynchrones donc on s'en fout). Dans les fait comment ça se passe ? Si tu fais un
read(fd, buff, SIZE);le noyau va se permettre de lire plus préventivement ? ou est-ce que ça s'applique principalement sur des appels comme mmap ?Au final, de ce que j'en comprend, si je fais un
cp -R /etc /etc-back & cp -R /usr /usr-backle noyau va prendre le premier fichier de /etc le mettre en cache pour l'écriture ultérieur, puis il va prendre le second fichier de /etc ou le premier fichier de /usr le lire et mettre en cache pour son écriture. Ça n'est pas idiot. Un intérêt c'est que c'est indépendant de l'utilisateur. Mais je pense que c'est un peu pointu de faire ça via les le nombre ou le ratio de pages sales (il peut y avoir des implications auquel je ne pense pas). Ça devrait être dans une politique de lecture.Par contre pour les gros fichiers (ceux qui sont trop gros pour que tu les mettent en cache), il vaut mieux utiliser une technique comme ultracopier, car il faut que l'utilisateur voit pourquoi son fichier n'est pas entrain d'être lu et qu'il puisse mettre en pause la copie qui le bloque (parce que la première est moins prioritaire pour lui). Bien sûr tu peut faire un Ctr+z sur le cp en question, mais c'est moins pratique il faut savoir que c'est bien lui qui bloque.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'ai du mal à comprendre
Posté par jben . Évalué à 4.
Je le répète mon intention en disant pour moi n'est pas de prendre les gens de haut, mais d'éviter de tirer une géneralité de mon comportement.
Le tunning de noyau à mes yeux (pour ne pas dire pour moi), c'est des truc un peu plus violent comme appliquer un patch pour transformer l'appel système
fsyncen truc qui ne fait rien. D'ailleurs la blague c'est que ce comportement est POSIX-compliant. À ce propos un thread en parle sur la lkml. Notez bien que je n'approuve pas ce patch, bien que je trouve que les applications utilisentfsyncà tord et à travers, il y a des cas où cet appel est justifié, l'usage d'une solution comme eat-my-data sur les programmes en faisant un usage non justifié, me semble préferable.Augmenter la quantité de pages sales autorisée ne reviens pas à augmenter le buffer de lecture, c'est uniquement les ecritures qui sont plus bufferisés. Donc la lecture devient la seule chose à faire à ce moment.
Lorsque tu parles de lecture préventive, c'est plus au niveau du readahead qu'il faut aller voir, et donc du coté de
hdparm. À noter quelaptop-mode-toolspermet aussi de facilement gerer ce comportement sans aller manger la doc dehdparmqui n'est pas des plus digestes.Pour le coup, je suis très rarement confronté à ce genre de problème. Je l'étais à une époque, mais j'ai pris l'habitude (en partie grâce au fait que je suis ammené à travailler sur des machines dont je ne suis pas le seul utilisateur) d'utiliser ionice. Quand j'ai besoin d'effectuer une tache gourmande en I/O, et que j'estime cette tache non prioritaire, je la lance en class idle pour ionice (à l'aide d'un
ionice -c 3, j'ai un alias). Il m'arrive aussi de redefinir un l'ionice d'un processus déjà lancé.[^] # Re: J'ai du mal à comprendre
Posté par alpha_one_x86 (site web personnel) . Évalué à 4.
La couche logiciel (user space) peu aussi corrompre tes fichiers (pointeur fou, oublie d'un mutex, …). Dire que tout vas biens alors que l'OS/FS à remonter une erreur (sur le resize par exemple, peu controlé, et souvent source de corruption).
Je réponds partiellement aux questions posés (surtout du point de vue utilisateur):
écritures sont asynchrones -> tant que le buffer n'est pas plein (buffer = écriture), après cela deviens synchrone
La 1ere lecture est toujours synchrone, les suivantes sont en cache généralement (cache = lecture). Donc pour un copie de fichier qu'on ne viens pas d'utiliser (souvent le cas pour moi), la lecture est synchrone, et l'OS n'as rien en cache.
Faire sauté les barrières aide bien sur ext4. Mais rien qu'avec, pas mal de lecture/écriture devienne synchrone.
Je sais pas comment marche linux, pour ça: Faudrait que certaines zone soit en mémoire, et qu'elle soit à la fois buffer et cache. C'est à dire que les fichiers temporaire (ceux de compilation de gcc par exemple), qui sont écrit, puis lu (directement depuis les page non écrite, et pas écrite garde comme cache), puis supprimé (installation de software pour gentoo) ce font que en mémoire sans jamais être ralenti pour le hdd. Et que si l'écriture n'as pas fini quand la suppression arrive, alors ont annule l'écriture, et ont supprime, et si la création du fichier n'as même pas commencer, alors ont ne fait rien sur le hdd.
Hors sur ça comme pas mal de point, je met des tmpfs (ram disk), car je suis trop ralenti par le hdd.
Il y as aussi cette histoire de zone chaude pour le hdd, nouveauté du noyau 3.8 si je me trompe. Mais pour moi les applications ne devrai pas lire/écrire en continue sur le hdd, si non c'est une problème souvent d'user space. Quand je vois que skype (mauvaise application) écrit tout le temps, à chaque contact qui se connecte…
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: J'ai du mal à comprendre
Posté par Grunt . Évalué à 10.
Y'a aussi pas mal d'infos sur des oeuvres propriétaires dont les DRM empêchent la lecture sous Linux. Ou des guerres de brevets au sujet de plateformes n'ayant rien à voir avec le libre (genre, Apple contre Microsoft).
Tu viens de te réveiller ?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: J'ai du mal à comprendre
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Supercopier étant libre, rien ne me choque. Linuxfr cause de linux d'abord, mais aussi du libre en général.
[^] # Re: J'ai du mal à comprendre
Posté par lolop (site web personnel) . Évalué à 10.
Si tu regardes la page sur laquelle tu arrives au premier lien, il y a écrit:
Ce qui me paraît tout à fait cohérent avec ce site, si tu prends la peine de regarder la page d'informations
En particulier, mais pas uniquement. Le libre ne se résume heureusement pas à Linux.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: J'ai du mal à comprendre
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 23 janvier 2013 à 09:08.
Il y a beaucoup de noms d'entreprise et d'assos qui sont historiques mais dont on ne change pas car ça nous plait et puis on s'en fout.
Ca n'en fait pas quelque chose de non cohérent.
Sinon, pour ta cohérence :
http://linuxfr.org/informations
"Elle a pour objectif de promouvoir les Logiciels Libres, en particulier Linux."
A ma connaissance le logiciel est libre, donc c'est cohérent.
Edit : argh, grillé par Laurent, ça m'apprendra à boire le café en même temps.
# Envisager une migration "invisible" de Supercopier en Ultracopier
Posté par Strash . Évalué à 9.
D'après ce que je comprends de tes divers messages à propos d'Ultracopier et de Supercopier, Ultracopier est supérieur en terme de fonctionnalités, de performances et en portabilité. Supercopier quand a lui a uniquement comme avantage sa notoriété et sa base d'utilisateurs.
Tu pourrais par exemple faire une version 4 de Supercopier qui serait en fait un Ultracopier "skinné" pour ressembler à Supercopier. Le tout en annonçant aux utilisateurs les gains de fonctionnalités et de performances + le support de nouvelles plateformes.
Avantages :
- Une seule base de code à maintenir (à part éventuellement l'interface)
- Tu conserves la base d'utilisateurs de Supercopier (qui a l'air importante)
- Les utilisateurs de Supercopier gagnent les avantages en terme de fonctionnalités et de performances
Inconvénients :
- Un peu de temps pour adapter l'interface ?
- Rien d'autre ?
Maintenant que tu as appris tout ce qu'il y avait à apprendre du code de Supercopier, où est l'intérêt de continuer à le maintenir ?
[^] # Re: Envisager une migration "invisible" de Supercopier en Ultracopier
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
J'ai pense à ça.
La base d'utilisateur de Supercopier est de 40x celle d'Ultracopier.
J'ai peur de les gens se sente arnaqué. Et je veux que les gens cherche explicitement Ultracopier, logiciel que j'ai fait de base. Au lieu qu'il attribue tout le mérite au ancien dev, et dise que j'ai juste fait un remake.
Ultracopier ressemble comme 2 goûte d'eau à l'interface d'Ultracopier pour la fenêtre de copie. (Il y as aussi une interface Windows pour les gens venant de windows, un interface teracopy, …)
Comme dit plus haut, l'intérêt de maintenir Supercopier est de pouvoir le comparé à Ultracopier, surtout en terme d'algo (car plein de dev utilise l'algo de Supercopier pour manip les fichiers), mais comparer les plateformes, les langages.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Envisager une migration "invisible" de Supercopier en Ultracopier
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Tu te fais vraiment beaucoup d'états d'âme, tu es le mainteneur de logiciels libres, libère toi de ça et fais ce qui te plaît ! Tu n'as aucun compte à rendre aux gens, ils t'ont pas payé pour faire ce soft, tu le fais parce que ça te plaît.
Perso j'arrêterais de maintenir Supercopier, et sur la page je mettrais un lien vers le dépôt/tarball avec le sources en l'état (pour ceux qui voudraient continuer à le faire évoluer), un lien vers les derniers binaires pour pas être trop chien, mais j'indiquerais surtout qu'il existe un autre logiciel plus performant avec éventuellement un tableau comparatif.
Parce que j'ai vraiment du mal à saisir cette idée de "maintenir Supercopier pour pouvoir le comparer à Ultracopier", tu te rajoutes du boulot juste pour remplir ton tableau comparatif tout en souhaitant que ce tableau soit en faveur d'Ultracopier, ce qu'il est déjà en réalité o_O
Pourquoi es-tu entravé par des contraintes qui accompagnent habituellement de la prestation payante de logiciel ? A moins que ça ne te dérange pas de faire évoluer les deux, mais d'un point de vue extérieur, on se demande "pourquoi ce gars propose deux logiciels similaires ? Il a pas confiance en son projet principal ? (ultracopier)"
[^] # Re: Envisager une migration "invisible" de Supercopier en Ultracopier
Posté par barmic . Évalué à 4.
Je trouve aussi que ça entretien une certaine confusion.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Envisager une migration "invisible" de Supercopier en Ultracopier
Posté par Philippe F (site web personnel) . Évalué à 5.
Je trouve ton attitude un peu violente vis à vis des utilisateurs.
C'est plutôt sympa de continuer à faire évoluer l'ancien logiciel, c'est souvent d'ailleurs comme ça que se passe le relai entre deux logiciels avec un nouveau développeur.
Perso, je rajouterai un dialogue bien visible au lancement du logiciel ou à l'utilisation qui dit que c'est la dernière mise à jour pour SuperCopier et que pour des corrections de bug et plus fonctionnel, il y a aussi UltraCopier.
Comme ça, les utilisateurs sont informés, ils sont pas pris en otage et en même temps tu proposes une version plus fonctionnelle de façon non forcée.
[^] # Re: Envisager une migration "invisible" de Supercopier en Ultracopier
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Ce qui me semble plutôt "violent", c'est le traitement que fait subir alpha_one_x86 envers lui-même (bon j'y vais un peu fort sur la formulation :)) : il travaille depuis des années sur un concurrent de Supercopier qui l'a maintenant bien dépassé (d'après ses comparatifs), il reprend ensuite les rennes de Supercopier avec la permission de l'auteur original (bon en fait, à ce moment là, ça me semblait déjà étrange (*)), et continue de le faire évoluer en parallèle de son propre bébé, tout en sachant que les deux softs partagent exactement le même créneau.
Alors OK, c'est très gentil et câlin avec les utilisateurs de Supercopier et après tout, si alpha_one_x86 s'éclate comme ça…
Oui en gros, ça s'éloigne pas trop de ce que je proposais : arrêter de faire évoluer un soft dont on maintient en parallèle un concurrent encore meilleur.
"pris en otage".
wow.
Donc en gros, si alpha_one_x86 ne fait pas évoluer Supercopier, il prend les utilisateurs de ce dernier "en otage" ? Tu te rends compte quand même que si alpha_one_x86 ne s'était pas proposé pour maintenir Supercopier, ça serait un abandonneware ?
(*) c'est un peu comme ces boîtes qui rachètent une entreprise concurrente uniquement pour la clientèle, qui continue à maintenir le produit maison pour pas perturber les utilisateurs, dans ces cas là, c'est avant tout une stratégie de captation de clientèle dans un contexte concurrentiel. Bon, c'est sûrement ça qu'a cherché alpha_one_x86 : rabattre de la "clientèle" vers son soft, je dois pas être assez calculateur…
[^] # Re: Envisager une migration "invisible" de Supercopier en Ultracopier
Posté par Emmanuel C . Évalué à 2.
Moi, j'aurais plutôt dit un génocide :-)
[^] # Re: Envisager une migration "invisible" de Supercopier en Ultracopier
Posté par steph1978 . Évalué à 3.
Je pertinente.
SuperCopier est avant tout une "marque" avec une très bonne notoriété sous windows. C'est souvent le premier soft que j'installe sur ce type de machine.
Donc tu pourrais n'avoir qu'une base de code et "brander" ultracopier sous la marque "supercopier" quitte à comparer les algos sur a même base de code.
En tout cas merci pour ton investissement sur ces projets.
# UltraCopier et KDE4
Posté par Fabien PRORIOL . Évalué à 3.
J'ai toujours étais un fan de supercopier lorsque j'étais encore sous windows.
C'était presque le 1er soft que j'installais sur ma machine.
Pour ce qui est d'UltraCopier, maintenant que je suis sous Linux, il faudrait que je retente un peu plus, mais j'avais testé il y a quelque temps, et je trouvais dommage la "non intégration" à KDE4…
Peut être que plutôt que de maintenir Super Copier, il serait intéressant d'essayer de faire une intégration dans KDE4…
Aujourd'hui, je trouve que la fonction copie de KDE4 manque vraiment de la fonction qui mettais dans une liste d'attente différente par media les fichiers a copier.
EX: Si je lance 5 copies sur mon disque USB, sa se met a ramer.
Puisque UltraCopier est en Qt, il serait peut être possible de l'intégrer proprement dans KDE4…
[^] # Re: UltraCopier et KDE4
Posté par alpha_one_x86 (site web personnel) . Évalué à 5.
Je +1, dommage la "non intégration" à KDE4. Mais c'est KDE qui décide.
J'ai essayer de faire un patch, je m'en suis pas sorti. Et de toute façon, Gnome et KDE ne semble pas pressé pour intégré le remplacement de leur copier/coller à la demande par un logiciel externe. Ca fait plusieurs année que je leur demande, Gnome/Nautilus m'as dit que ça sera fait dans l'avenir, mais toujours rien.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: UltraCopier et KDE4
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
Le plus con, c'est que j'oublie toujours d'utiliser Ultracopier pour faire mes copies, et vu que KDE et Linux ne permettent pas l'interception, je ne m'en sert que très peu.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: UltraCopier et KDE4
Posté par ʭ ☯ . Évalué à 2.
Ouaip, pour ma part j'utilise les boutons play/pause de KDE4 pour les copies qui concernent les mêmes disques : finalement, c'est très rare que ça m'arrive.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: UltraCopier et KDE4
Posté par barmic . Évalué à 3.
Nautilus a forké il y a peu peut être que les développeurs en question seraient plus rapide à mettre en forme ta demande. Les logiciels plus petits ou plus récents ont des développeurs qui ont tendance à être plus réactifs.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: UltraCopier et KDE4
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Ou les trouvés? Dsl, j'utilise pas Nautilus, donc je suis pas trés au courrant sur ça.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: UltraCopier et KDE4
Posté par barmic . Évalué à 1.
Je pensais en particulier à Nemo créé par Mint.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: UltraCopier et KDE4
Posté par EcliptuX . Évalué à 1.
J'allais le dire.
Nemo est un très bon fork de Nautilus et il est possible que les dev soient plus enclin à implémenter une interception avec Supercopier/Ultracopier.
En fait de ce que je comprends, cette faculté à intercepter dépends plus du gestionnaire de fichier utilisé (Thunar, Dolplhin, Nemo, Nautilus, mc(?), ranger(?)…) que du gestionnaire d'environnement (KDE, Gnome, XFCE, i3, WMS…) c'est bien ça ?
[^] # Re: UltraCopier et KDE4
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Oui, car c'est le gestionnaire de fichiers qui décide d'envoyer la copie sur un logiciel extérieur.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: UltraCopier et KDE4
Posté par EcliptuX . Évalué à 1.
ok donc reste à convaincre les dev….
ça marcherait avec des appli en console (mc, ranger…) ?
[^] # Re: UltraCopier et KDE4
Posté par lolop (site web personnel) . Évalué à 3.
Une nouvelle norme freedesktop ?
Avec une bête variablement d'environnement
Qui permette à un utilisateur d'indiquer qu'il veut que ses outils délèguent les copies locales (enfin, à moins qu'Ultracopier fasse aussi du scp, ftp…).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: UltraCopier et KDE4
Posté par alpha_one_x86 (site web personnel) . Évalué à 4.
J'ai déjà proposé à free desktop une norme. Pas de réponse. (Norme de communication entre l'application de copie et le gestionnaire de fichier).
Avec une bête variablement d'environnement, c'est impossible, car ça impose des commandes uniforme, ça ne supportera pas les fichiers avec des noms corrompu, …
Ultracopier est prévu aussi pour d'autres protocole, mais leur utilisations est restreinte (dépends du support du moteur de copie).
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: UltraCopier et KDE4
Posté par barmic . Évalué à 3.
Je m’étais posé la question hier. Pour freedesktop il faudrait pas passer par des appels dbus ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: UltraCopier et KDE4
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
J'ai fait une version simplifié en dbus.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# Et pourquoi pas une intégration dans les gestionnaires de fichiers ?
Posté par EcliptuX . Évalué à 2.
Je suis de loin Ultracopier depuis quelques temps, car je suis très souvent confronté au problème de fatigue des têtes de lectures quand il m'arrive à devoir copier plusieurs fichiers l'un après l'autre.
Néanmoins l'idée d'utiliser un logiciel "en plus" pour gérer mes copies m'embête un peu.
Pourquoi n'existe-t-il pas de manière native, au sein des différents gestionnaires de fichiers (Nemo, Nautilus, Dolphin, Thunar…) un système qui permettrait, par exemple, de mettre "à la queue" un fichier en copie dans le même répertoire lorsqu'on dépose un fichier sur une fenêtre de copie existante ?
Ne pourrait-on pas implémenter des bouts de codes d'Ultracopier dans ces gestionnaires de fichiers sous la forme de plugins par exemple ?
J'en rêve la nuit !
[^] # Re: Et pourquoi pas une intégration dans les gestionnaires de fichiers ?
Posté par barmic . Évalué à 2.
Non ce qu'il faudrait c'est un hook. Comme ça tu ne te rend pas compte que tu as affaire à un nouveau logiciel et ça permet à ceux qui n'utilisent pas ces gestionnaires de fichiers de s'en servir.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et pourquoi pas une intégration dans les gestionnaires de fichiers ?
Posté par alpha_one_x86 (site web personnel) . Évalué à 3.
Ou juste permettre l'utilisation de logiciel de copie externe (je lute depuis des années pour ça avec linux), car il ont chaqu'un leur spécificité.
Car reprendre des bouts de logiciel fait pour un autre logiciel. Et un truc de base qui me manquais quand j'avais regarder dans les libs de KDE, c'été la limitation de la vitesse.
Par contre j'ai bien documenté les algos, et je suis ouvert à toutes discutions pour aider les copieurs fichiers (qui doivent resté simple pour les novices) à s'améliorer.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# A referral was returned from the server
Posté par alpha_one_x86 (site web personnel) . Évalué à 1.
Beaucoup de gens me reporte:
Supercopier 3.0.0.0 returns a « A referral was returned from the server » error when I try to start it.
Qui me peu me confirmé, et m'aide à débugé?
Ici l'application marche.
Merci d'avance.
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: A referral was returned from the server
Posté par 16aR . Évalué à 1. Dernière modification le 06 février 2013 à 10:54.
J'ai téléchargé la version setup 32 bits et la version portable. Je suis derrière un proxy d'entreprise. Peut-être que la version 32 bits s'est mal téléchargé, mais en tout cas, l'exe m'a ouvert une console avec le curseur qui bougeait dans tous les sens et rien d'autre.
La version portable, je l'ai lancé, et il n'interceptait pas les copier coller dans l'explorer.
J'étais admin sous winxp, j'ai killé explorer, relancé alors que SC tournait déjà, ca n'a pas aidé non plus.
Je vais installer UC à la place ;)
En tout cas, bravo pour ta ténacité, ca fait pas mal de temps que tu bosses dessus et ça à l'air de bien s'améliorer !
En tout cas, pas de referral pour ma part.
# Usage avec SMB
Posté par Poppu . Évalué à 1.
La dernière version UltraCopier ne résout toujours pas les problèmes avec SMB ?
J'avoue que c'est ce qui m'a fait arrêter l'usage d'Ultra Copier : pratique tant que je suis en local, mais dès que je tape sur mon NAS ça plante… Ne serait-il pas possible de rajouter au moins une option qui fasse que UltraCopier rende la main au gestionnaire de copie natif quand il détecte une copie vers un montage SMB ?
Je sais bien que ce n'est pas l'endroit pour faire une demande, mais je suis sûr que c'est une des raisons qui freinent son adoption… Car pour le local, UltraCopier est tout simplement génial !
C'est du très bon boulot, et je te remercie beaucoup de nous le faire partager !
[^] # Re: Usage avec SMB
Posté par alpha_one_x86 (site web personnel) . Évalué à 3. Dernière modification le 25 janvier 2013 à 11:31.
Bas normal avec Ultracopier, tout les problèmes sont résolut.
Je copie depuis et vers les partages réseaux tout les jours avec Ultracopier.
Si il y as toujours des problèmes, me contacter. Je corrigerai rapide.
Oui, pas tellement l'endroit vu que c'est une news pour Supercopier…
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: Usage avec SMB
Posté par alpha_one_x86 (site web personnel) . Évalué à 2. Dernière modification le 25 janvier 2013 à 11:38.
*normalement
*rapidement
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.