Lors de la copie de plusieurs éléments d'un endroit à l'autre, les
boîtes de dialogue affichent simplement "Copie de xxx éléments"... sans
indiquer ce qui est copié. Y a-t-il moyen de savoir ce qui est copié ?
Ceci pour choisir certains éléments plutôt que d'autres, lorsque le
volume de destination est saturé.
Lors de la copie de plusieurs éléments d'un endroit à l'autre, les boîtes de dialogue affichent simplement "Copie de xxx éléments"... sans indiquer ce qui est copié. Y a-t-il moyen de savoir ce qui est copié ? Ceci pour choisir certains éléments plutôt que d'autres, lorsque le volume de destination est saturé.
Euh!, ancien utilisateur de Windows ? ;-)
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows. ;-(
-- Jacques PERROCHEAU Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510 Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
In article <48089a47$0$6746$426a74cc@news.free.fr>,
Daedale <daedale@free.fr> wrote:
Lors de la copie de plusieurs éléments d'un endroit à l'autre, les
boîtes de dialogue affichent simplement "Copie de xxx éléments"... sans
indiquer ce qui est copié. Y a-t-il moyen de savoir ce qui est copié ?
Ceci pour choisir certains éléments plutôt que d'autres, lorsque le
volume de destination est saturé.
Euh!, ancien utilisateur de Windows ? ;-)
Il me semble bien que le Finder de Mac OS X ne commence la copie
qu'après avoir calculé que ce que tu copies tient sur le volume de
destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows.
;-(
--
Jacques PERROCHEAU
Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510
Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex
Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
Lors de la copie de plusieurs éléments d'un endroit à l'autre, les boîtes de dialogue affichent simplement "Copie de xxx éléments"... sans indiquer ce qui est copié. Y a-t-il moyen de savoir ce qui est copié ? Ceci pour choisir certains éléments plutôt que d'autres, lorsque le volume de destination est saturé.
Euh!, ancien utilisateur de Windows ? ;-)
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows. ;-(
-- Jacques PERROCHEAU Synthèse et Electrosynthèse Organiques, C.N.R.S. UMR 6510 Université de Rennes I, Campus de Beaulieu, F-35042 RENNES Cedex Tel: +33 2 23 23 63 74, Fax: +33 2 23 23 63 74
cf
Jacques Perrocheau wrote:
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows. ;-(
Effectivement, sur ce point (calcul de l'espace disponible avant de commencer la copie), le Finder est correctement pensé. Ce qui ne l'empêche pas d'avoir de "graves" lacunes par ailleurs, comme par exemple quand au cours d'une copie multiple il rencontre un nom de fichier qui ne lui plaît pas, d'arrêter purement et simplement la copie (à l'utilisateur de se dém^Hbrouiller pour retrouver le fichier fautif, le corriger, et soit relancer l'ensemble de la copie -- vachement pratique si il y en avait des gigas -- soit essayer de la terminer manuellement à partir de là où elle s'est arrêtée, fichier par fichier puis dossier par dossier -- encore plus pratique --). Tout ça en espérant qu'il n'y aura pas trop d'autres fichiers dans le même cas (ce qui arrive neuf fois sur dix).
Un simple dialogue "arrêter/ignorer ce fichier/ignorer tous" aurait été un minimum (et la génération d'un rapport d'erreur contenant le nom des fichiers non copiés aurait aussi été bienvenue).
Pas chapeau à Apple, sur ce coup-là (cela dit, je ne sait pas comment se débrouillent les différentes version de Windows dans ce genre de cas, mais ça m'étonnerait que ce soit pire).
Note : je parle des versions pré-Léopard, peut-être que la version 10.5 a amélioré les choses ?
A++ -- Christian
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> wrote:
Il me semble bien que le Finder de Mac OS X ne commence la copie
qu'après avoir calculé que ce que tu copies tient sur le volume de
destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows.
;-(
Effectivement, sur ce point (calcul de l'espace disponible avant de
commencer la copie), le Finder est correctement pensé. Ce qui ne
l'empêche pas d'avoir de "graves" lacunes par ailleurs, comme par
exemple quand au cours d'une copie multiple il rencontre un nom de
fichier qui ne lui plaît pas, d'arrêter purement et simplement la copie
(à l'utilisateur de se dém^Hbrouiller pour retrouver le fichier fautif,
le corriger, et soit relancer l'ensemble de la copie -- vachement
pratique si il y en avait des gigas -- soit essayer de la terminer
manuellement à partir de là où elle s'est arrêtée, fichier par fichier
puis dossier par dossier -- encore plus pratique --). Tout ça en
espérant qu'il n'y aura pas trop d'autres fichiers dans le même cas (ce
qui arrive neuf fois sur dix).
Un simple dialogue "arrêter/ignorer ce fichier/ignorer tous" aurait été
un minimum (et la génération d'un rapport d'erreur contenant le nom des
fichiers non copiés aurait aussi été bienvenue).
Pas chapeau à Apple, sur ce coup-là (cela dit, je ne sait pas comment se
débrouillent les différentes version de Windows dans ce genre de cas,
mais ça m'étonnerait que ce soit pire).
Note : je parle des versions pré-Léopard, peut-être que la version 10.5
a amélioré les choses ?
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows. ;-(
Effectivement, sur ce point (calcul de l'espace disponible avant de commencer la copie), le Finder est correctement pensé. Ce qui ne l'empêche pas d'avoir de "graves" lacunes par ailleurs, comme par exemple quand au cours d'une copie multiple il rencontre un nom de fichier qui ne lui plaît pas, d'arrêter purement et simplement la copie (à l'utilisateur de se dém^Hbrouiller pour retrouver le fichier fautif, le corriger, et soit relancer l'ensemble de la copie -- vachement pratique si il y en avait des gigas -- soit essayer de la terminer manuellement à partir de là où elle s'est arrêtée, fichier par fichier puis dossier par dossier -- encore plus pratique --). Tout ça en espérant qu'il n'y aura pas trop d'autres fichiers dans le même cas (ce qui arrive neuf fois sur dix).
Un simple dialogue "arrêter/ignorer ce fichier/ignorer tous" aurait été un minimum (et la génération d'un rapport d'erreur contenant le nom des fichiers non copiés aurait aussi été bienvenue).
Pas chapeau à Apple, sur ce coup-là (cela dit, je ne sait pas comment se débrouillent les différentes version de Windows dans ce genre de cas, mais ça m'étonnerait que ce soit pire).
Note : je parle des versions pré-Léopard, peut-être que la version 10.5 a amélioré les choses ?
A++ -- Christian
Paul Gaborit
À (at) Fri, 18 Apr 2008 16:05:43 +0200, Jacques Perrocheau écrivait (wrote):
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows. ;-(
Que se passe-t-il si le calcul initial indique que la copie est possible mais que durant la copie, je crée un énorme fichier qui remplit tout le disque de destination ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 18 Apr 2008 16:05:43 +0200,
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> écrivait (wrote):
Il me semble bien que le Finder de Mac OS X ne commence la copie
qu'après avoir calculé que ce que tu copies tient sur le volume de
destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows.
;-(
Que se passe-t-il si le calcul initial indique que la copie est
possible mais que durant la copie, je crée un énorme fichier qui
remplit tout le disque de destination ?
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 18 Apr 2008 16:05:43 +0200, Jacques Perrocheau écrivait (wrote):
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows. ;-(
Que se passe-t-il si le calcul initial indique que la copie est possible mais que durant la copie, je crée un énorme fichier qui remplit tout le disque de destination ?
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Eric Levenez
Le 18/04/08 16:53, dans <1ifl989.170fgkb12ij6lpN%, « Christian Fauchier » a écrit :
Effectivement, sur ce point (calcul de l'espace disponible avant de commencer la copie), le Finder est correctement pensé. Ce qui ne l'empêche pas d'avoir de "graves" lacunes par ailleurs, comme par exemple quand au cours d'une copie multiple il rencontre un nom de fichier qui ne lui plaît pas, d'arrêter purement et simplement la copie (à l'utilisateur de se dém^Hbrouiller pour retrouver le fichier fautif, le corriger, et soit relancer l'ensemble de la copie -- vachement pratique si il y en avait des gigas -- soit essayer de la terminer manuellement à partir de là où elle s'est arrêtée, fichier par fichier puis dossier par dossier -- encore plus pratique --).
Le plus embêtant dans la copie de fichier du Finder de Mac OS X c'est qu'il ne sait pas merger deux répertoires, la cible est toujours perdue. Donc si on relance une copie qui s'est planté au milieu, on a toutes les chances de perdre des fichiers lors de la seconde copie...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 18/04/08 16:53, dans <1ifl989.170fgkb12ij6lpN%cf@nospam.invalid>,
« Christian Fauchier » <cf@nospam.invalid> a écrit :
Effectivement, sur ce point (calcul de l'espace disponible avant de
commencer la copie), le Finder est correctement pensé. Ce qui ne
l'empêche pas d'avoir de "graves" lacunes par ailleurs, comme par
exemple quand au cours d'une copie multiple il rencontre un nom de
fichier qui ne lui plaît pas, d'arrêter purement et simplement la copie
(à l'utilisateur de se dém^Hbrouiller pour retrouver le fichier fautif,
le corriger, et soit relancer l'ensemble de la copie -- vachement
pratique si il y en avait des gigas -- soit essayer de la terminer
manuellement à partir de là où elle s'est arrêtée, fichier par fichier
puis dossier par dossier -- encore plus pratique --).
Le plus embêtant dans la copie de fichier du Finder de Mac OS X c'est qu'il
ne sait pas merger deux répertoires, la cible est toujours perdue. Donc si
on relance une copie qui s'est planté au milieu, on a toutes les chances de
perdre des fichiers lors de la seconde copie...
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 18/04/08 16:53, dans <1ifl989.170fgkb12ij6lpN%, « Christian Fauchier » a écrit :
Effectivement, sur ce point (calcul de l'espace disponible avant de commencer la copie), le Finder est correctement pensé. Ce qui ne l'empêche pas d'avoir de "graves" lacunes par ailleurs, comme par exemple quand au cours d'une copie multiple il rencontre un nom de fichier qui ne lui plaît pas, d'arrêter purement et simplement la copie (à l'utilisateur de se dém^Hbrouiller pour retrouver le fichier fautif, le corriger, et soit relancer l'ensemble de la copie -- vachement pratique si il y en avait des gigas -- soit essayer de la terminer manuellement à partir de là où elle s'est arrêtée, fichier par fichier puis dossier par dossier -- encore plus pratique --).
Le plus embêtant dans la copie de fichier du Finder de Mac OS X c'est qu'il ne sait pas merger deux répertoires, la cible est toujours perdue. Donc si on relance une copie qui s'est planté au milieu, on a toutes les chances de perdre des fichiers lors de la seconde copie...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Jacques Perrocheau
In article , Paul Gaborit wrote:
Que se passe-t-il si le calcul initial indique que la copie est possible mais que durant la copie, je crée un énorme fichier qui remplit tout le disque de destination ?
No se, pour remplir avec un seul fichier soit il faut être vicieux, soit inconscient, ;-) genre il ne restait que quelque Mo sur le volume de destination avant de commencer l'opération.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <wt9prsnqj8x.fsf@marceau.enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Que se passe-t-il si le calcul initial indique que la copie est
possible mais que durant la copie, je crée un énorme fichier qui
remplit tout le disque de destination ?
No se, pour remplir avec un seul fichier soit il faut être vicieux, soit
inconscient, ;-) genre il ne restait que quelque Mo sur le volume de
destination avant de commencer l'opération.
--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
Que se passe-t-il si le calcul initial indique que la copie est possible mais que durant la copie, je crée un énorme fichier qui remplit tout le disque de destination ?
No se, pour remplir avec un seul fichier soit il faut être vicieux, soit inconscient, ;-) genre il ne restait que quelque Mo sur le volume de destination avant de commencer l'opération.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
Daedale
In article <48089a47$0$6746$, Daedale wrote:
Euh!, ancien utilisateur de Windows ? ;-)
ambidextre depuis des années !
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
pas quand on ajoute au fur et à mesure, évidemment... et c'est ce qui m'est arrivé (vers une clé usb). Or j'aurais voulu choisir, en cours de copie, quels répertoires copier, quels répertoires cesser de copier. Disons que quand il s'agit de fichiers, la boîte de dialogue donne le nom du fichier ; par contre, lors de la copie d'un dossier, pas de nom dans la boîte de dialogue, et c'est une info en moins, dont je me serais volontiers servi ;-)
In article <48089a47$0$6746$426a74cc@news.free.fr>,
Daedale <daedale@free.fr> wrote:
Euh!, ancien utilisateur de Windows ? ;-)
ambidextre depuis des années !
Il me semble bien que le Finder de Mac OS X ne commence la copie
qu'après avoir calculé que ce que tu copies tient sur le volume de
destination, comme le faisait le Finder de Mac OS 9.
pas quand on ajoute au fur et à mesure, évidemment... et c'est ce qui
m'est arrivé (vers une clé usb). Or j'aurais voulu choisir, en cours de
copie, quels répertoires copier, quels répertoires cesser de copier.
Disons que quand il s'agit de fichiers, la boîte de dialogue donne le
nom du fichier ; par contre, lors de la copie d'un dossier, pas de nom
dans la boîte de dialogue, et c'est une info en moins, dont je me serais
volontiers servi ;-)
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
pas quand on ajoute au fur et à mesure, évidemment... et c'est ce qui m'est arrivé (vers une clé usb). Or j'aurais voulu choisir, en cours de copie, quels répertoires copier, quels répertoires cesser de copier. Disons que quand il s'agit de fichiers, la boîte de dialogue donne le nom du fichier ; par contre, lors de la copie d'un dossier, pas de nom dans la boîte de dialogue, et c'est une info en moins, dont je me serais volontiers servi ;-)
Daedale
dans la boîte de dialogue, et c'est une info en moins, dont je me serais volontiers servi ;-)
le smiley a valeur de "e"
dans la boîte de dialogue, et c'est une info en moins, dont je me serais
volontiers servi ;-)
dans la boîte de dialogue, et c'est une info en moins, dont je me serais volontiers servi ;-)
le smiley a valeur de "e"
pas.de.spam
Christian Fauchier wrote:
Jacques Perrocheau wrote:
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows. ;-(
Effectivement, sur ce point (calcul de l'espace disponible avant de commencer la copie), le Finder est correctement pensé. Ce qui ne l'empêche pas d'avoir de "graves" lacunes par ailleurs, comme par exemple quand au cours d'une copie multiple il rencontre un nom de fichier qui ne lui plaît pas, d'arrêter purement et simplement la copie (à l'utilisateur de se dém^Hbrouiller pour retrouver le fichier fautif, le corriger, et soit relancer l'ensemble de la copie -- vachement pratique si il y en avait des gigas -- soit essayer de la terminer manuellement à partir de là où elle s'est arrêtée, fichier par fichier puis dossier par dossier -- encore plus pratique --). Tout ça en espérant qu'il n'y aura pas trop d'autres fichiers dans le même cas (ce qui arrive neuf fois sur dix).
Un simple dialogue "arrêter/ignorer ce fichier/ignorer tous" aurait été un minimum (et la génération d'un rapport d'erreur contenant le nom des fichiers non copiés aurait aussi été bienvenue).
Pas chapeau à Apple, sur ce coup-là (cela dit, je ne sait pas comment se débrouillent les différentes version de Windows dans ce genre de cas, mais ça m'étonnerait que ce soit pire).
Note : je parle des versions pré-Léopard, peut-être que la version 10.5 a amélioré les choses ?
De tout temps sur Mac, la copie de fichiers est à mon sens ce qu'on peut faire de pire en anti ergonomie (ou de mieux, dans ce sens là).
IL pourait y avoir une option lorsque des dossiers de même nom sont présents dans la destination, permettant de somplement ajouter les dossiers manquants et éventuellement de compléter les dossiers incomplets.
De même lorsque l'on lance successivement plusieurs copies. Celles ci se font en même temps, ralentissant gravement les disques qui doivent faire des aller-retours permanents. ALors qu'il aurait été tellement simple de faire une file d'attente pour des éléments provenant de mêmes disques, et/ou à destination de mêmes disques.
D'ailleurs, il manque cruellement un utilitaire de comparaison de contenu de dossiers, pour, en cas d'échec en plein milieu d'une grosse copie, voir rapidement, ce qui manque et où
-- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Christian Fauchier <cf@nospam.invalid> wrote:
Jacques Perrocheau <Jacques.Perrocheau@univ-rennes1.fr> wrote:
Il me semble bien que le Finder de Mac OS X ne commence la copie
qu'après avoir calculé que ce que tu copies tient sur le volume de
destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows.
;-(
Effectivement, sur ce point (calcul de l'espace disponible avant de
commencer la copie), le Finder est correctement pensé. Ce qui ne
l'empêche pas d'avoir de "graves" lacunes par ailleurs, comme par
exemple quand au cours d'une copie multiple il rencontre un nom de
fichier qui ne lui plaît pas, d'arrêter purement et simplement la copie
(à l'utilisateur de se dém^Hbrouiller pour retrouver le fichier fautif,
le corriger, et soit relancer l'ensemble de la copie -- vachement
pratique si il y en avait des gigas -- soit essayer de la terminer
manuellement à partir de là où elle s'est arrêtée, fichier par fichier
puis dossier par dossier -- encore plus pratique --). Tout ça en
espérant qu'il n'y aura pas trop d'autres fichiers dans le même cas (ce
qui arrive neuf fois sur dix).
Un simple dialogue "arrêter/ignorer ce fichier/ignorer tous" aurait été
un minimum (et la génération d'un rapport d'erreur contenant le nom des
fichiers non copiés aurait aussi été bienvenue).
Pas chapeau à Apple, sur ce coup-là (cela dit, je ne sait pas comment se
débrouillent les différentes version de Windows dans ce genre de cas,
mais ça m'étonnerait que ce soit pire).
Note : je parle des versions pré-Léopard, peut-être que la version 10.5
a amélioré les choses ?
De tout temps sur Mac, la copie de fichiers est à mon sens ce qu'on peut
faire de pire en anti ergonomie (ou de mieux, dans ce sens là).
IL pourait y avoir une option lorsque des dossiers de même nom sont
présents dans la destination, permettant de somplement ajouter les
dossiers manquants et éventuellement de compléter les dossiers
incomplets.
De même lorsque l'on lance successivement plusieurs copies. Celles ci se
font en même temps, ralentissant gravement les disques qui doivent faire
des aller-retours permanents. ALors qu'il aurait été tellement simple de
faire une file d'attente pour des éléments provenant de mêmes disques,
et/ou à destination de mêmes disques.
D'ailleurs, il manque cruellement un utilitaire de comparaison de
contenu de dossiers, pour, en cas d'échec en plein milieu d'une grosse
copie, voir rapidement, ce qui manque et où
Il me semble bien que le Finder de Mac OS X ne commence la copie qu'après avoir calculé que ce que tu copies tient sur le volume de destination, comme le faisait le Finder de Mac OS 9.
Si ce n'était plus le cas, ce serait grave, un alignement sur Windows. ;-(
Effectivement, sur ce point (calcul de l'espace disponible avant de commencer la copie), le Finder est correctement pensé. Ce qui ne l'empêche pas d'avoir de "graves" lacunes par ailleurs, comme par exemple quand au cours d'une copie multiple il rencontre un nom de fichier qui ne lui plaît pas, d'arrêter purement et simplement la copie (à l'utilisateur de se dém^Hbrouiller pour retrouver le fichier fautif, le corriger, et soit relancer l'ensemble de la copie -- vachement pratique si il y en avait des gigas -- soit essayer de la terminer manuellement à partir de là où elle s'est arrêtée, fichier par fichier puis dossier par dossier -- encore plus pratique --). Tout ça en espérant qu'il n'y aura pas trop d'autres fichiers dans le même cas (ce qui arrive neuf fois sur dix).
Un simple dialogue "arrêter/ignorer ce fichier/ignorer tous" aurait été un minimum (et la génération d'un rapport d'erreur contenant le nom des fichiers non copiés aurait aussi été bienvenue).
Pas chapeau à Apple, sur ce coup-là (cela dit, je ne sait pas comment se débrouillent les différentes version de Windows dans ce genre de cas, mais ça m'étonnerait que ce soit pire).
Note : je parle des versions pré-Léopard, peut-être que la version 10.5 a amélioré les choses ?
De tout temps sur Mac, la copie de fichiers est à mon sens ce qu'on peut faire de pire en anti ergonomie (ou de mieux, dans ce sens là).
IL pourait y avoir une option lorsque des dossiers de même nom sont présents dans la destination, permettant de somplement ajouter les dossiers manquants et éventuellement de compléter les dossiers incomplets.
De même lorsque l'on lance successivement plusieurs copies. Celles ci se font en même temps, ralentissant gravement les disques qui doivent faire des aller-retours permanents. ALors qu'il aurait été tellement simple de faire une file d'attente pour des éléments provenant de mêmes disques, et/ou à destination de mêmes disques.
D'ailleurs, il manque cruellement un utilitaire de comparaison de contenu de dossiers, pour, en cas d'échec en plein milieu d'une grosse copie, voir rapidement, ce qui manque et où
-- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Julien Salort
(Pierre-Olivier TAUBATY) writes:
De tout temps sur Mac, la copie de fichiers est à mon sens ce qu'on peut faire de pire en anti ergonomie (ou de mieux, dans ce sens là ).
à l'heure actuelle, la seule façon de faire la même chose, à ma connaissance, c'est de faire la copie avec un outil genre rsync en ligne de commande (fournie de base avec Mac OS X). Je me demande d'ailleurs pourquoi le Finder n'utilise pas rsync pour faire la copie...
à l'heure actuelle, la seule façon de faire la même chose, à ma
connaissance, c'est de faire la copie avec un outil genre rsync en ligne
de commande (fournie de base avec Mac OS X).
Je me demande d'ailleurs pourquoi le Finder n'utilise pas rsync pour
faire la copie...
à l'heure actuelle, la seule façon de faire la même chose, à ma connaissance, c'est de faire la copie avec un outil genre rsync en ligne de commande (fournie de base avec Mac OS X). Je me demande d'ailleurs pourquoi le Finder n'utilise pas rsync pour faire la copie...
