Le 15/11/2011 14:27, Zork a écrit :La restauration ne touche pas au contenu de la base des données,
Ben, faudrait savoir, je te cite dans ton précédent message :
Pierre :Faire une restauration à un point antérieur va, je pense,
reprendre la base de registre à un état antécédent, donc supprimer les
nouvelles entrées.
Zork :Oui
Alors, c'est oui ou c'est non ?
Cordialement.
Pierreelle ne touche qu'aux fichiers systèmes par comparaison entre la
situation actuelle et l'image postérieure.
Le 15/11/2011 14:27, Zork a écrit :
La restauration ne touche pas au contenu de la base des données,
Ben, faudrait savoir, je te cite dans ton précédent message :
Pierre :Faire une restauration à un point antérieur va, je pense,
reprendre la base de registre à un état antécédent, donc supprimer les
nouvelles entrées.
Zork :Oui
Alors, c'est oui ou c'est non ?
Cordialement.
Pierre
elle ne touche qu'aux fichiers systèmes par comparaison entre la
situation actuelle et l'image postérieure.
Le 15/11/2011 14:27, Zork a écrit :La restauration ne touche pas au contenu de la base des données,
Ben, faudrait savoir, je te cite dans ton précédent message :
Pierre :Faire une restauration à un point antérieur va, je pense,
reprendre la base de registre à un état antécédent, donc supprimer les
nouvelles entrées.
Zork :Oui
Alors, c'est oui ou c'est non ?
Cordialement.
Pierreelle ne touche qu'aux fichiers systèmes par comparaison entre la
situation actuelle et l'image postérieure.
La restauration attend que le taux de la TVA augmente... LOL
La restauration attend que le taux de la TVA augmente... LOL
La restauration attend que le taux de la TVA augmente... LOL
Le 15/11/2011 11:37, Zork a écrit :
"ChP"Supposons que la mise à jour du logiciel (dont je pense qu'elle est la
source de mes ennuis) ait modifié des entrées dans la base de reg istre
et ait créé/modifié des fichiers systèmes.
Oui.Faire une restauration à un point antérieur va, je pense, reprend re la
base de registre à un état antécédent, donc supprimer les nou velles
entrées.
Oui
Je suppose que cette restauration va aussi rétablir/supprimerla création/modification des fichiers systèmes.
Oui
Dans ces condition, lamise à jour de mon logiciel va devenir complètement boîteuse.
Non
Je ne vois pas comment elle ne pourrait pas être boîteuse. Mon
raisonnement :
Après la mise à jour, les fichiers de l'ancienne version n'existent plus
(je ne pense pas que le processus de restauration se charge de stocker
les anciens fichiers) et les nouveaux nécessitent d'avoir les
modifications faites dans la base de registre et dans les fichiers
systèmes. Or la restauration à une date antérieure va supprimer l es
modifications de la base de données et des fichiers systèmes sans
replacer les fichiers de l'ancienne version. On se retrouve donc avec
des fichiers d'une nouvelle version avec une base et des fichiers
systèmes correspondants à l'ancienne. Vrai, faux ?
Ta mise à jour va être simplement annulée, c'est l'intérêt s i la MàJ de
ton logiciel s'est mal passée.
Mais attention à la date indiquée pour ton point de restauration !
S'il est ancien il y a bcp de modifications systèmes qui vont
disparaitre avec.
En général quand une mise à jour est bien faite elle réalise d ans son
package le point de restauration.
Si ce n'est pas le cas il est prudent de le faire manuellement sois-mê me
avant.
Donc vérifie cette date en priorité avant de faire quoi que ce soi t,
Tu as raison, il faut aller chercher le point le plus proche possible.j'ai vue des points de restauration dater de la mise en service du pc !
Si si ...
Cordialement.
Pierre
Le 15/11/2011 11:37, Zork a écrit :
"ChP"
Supposons que la mise à jour du logiciel (dont je pense qu'elle est la
source de mes ennuis) ait modifié des entrées dans la base de reg istre
et ait créé/modifié des fichiers systèmes.
Oui.
Faire une restauration à un point antérieur va, je pense, reprend re la
base de registre à un état antécédent, donc supprimer les nou velles
entrées.
Oui
Je suppose que cette restauration va aussi rétablir/supprimer
la création/modification des fichiers systèmes.
Oui
Dans ces condition, la
mise à jour de mon logiciel va devenir complètement boîteuse.
Non
Je ne vois pas comment elle ne pourrait pas être boîteuse. Mon
raisonnement :
Après la mise à jour, les fichiers de l'ancienne version n'existent plus
(je ne pense pas que le processus de restauration se charge de stocker
les anciens fichiers) et les nouveaux nécessitent d'avoir les
modifications faites dans la base de registre et dans les fichiers
systèmes. Or la restauration à une date antérieure va supprimer l es
modifications de la base de données et des fichiers systèmes sans
replacer les fichiers de l'ancienne version. On se retrouve donc avec
des fichiers d'une nouvelle version avec une base et des fichiers
systèmes correspondants à l'ancienne. Vrai, faux ?
Ta mise à jour va être simplement annulée, c'est l'intérêt s i la MàJ de
ton logiciel s'est mal passée.
Mais attention à la date indiquée pour ton point de restauration !
S'il est ancien il y a bcp de modifications systèmes qui vont
disparaitre avec.
En général quand une mise à jour est bien faite elle réalise d ans son
package le point de restauration.
Si ce n'est pas le cas il est prudent de le faire manuellement sois-mê me
avant.
Donc vérifie cette date en priorité avant de faire quoi que ce soi t,
Tu as raison, il faut aller chercher le point le plus proche possible.
j'ai vue des points de restauration dater de la mise en service du pc !
Si si ...
Cordialement.
Pierre
Le 15/11/2011 11:37, Zork a écrit :
"ChP"Supposons que la mise à jour du logiciel (dont je pense qu'elle est la
source de mes ennuis) ait modifié des entrées dans la base de reg istre
et ait créé/modifié des fichiers systèmes.
Oui.Faire une restauration à un point antérieur va, je pense, reprend re la
base de registre à un état antécédent, donc supprimer les nou velles
entrées.
Oui
Je suppose que cette restauration va aussi rétablir/supprimerla création/modification des fichiers systèmes.
Oui
Dans ces condition, lamise à jour de mon logiciel va devenir complètement boîteuse.
Non
Je ne vois pas comment elle ne pourrait pas être boîteuse. Mon
raisonnement :
Après la mise à jour, les fichiers de l'ancienne version n'existent plus
(je ne pense pas que le processus de restauration se charge de stocker
les anciens fichiers) et les nouveaux nécessitent d'avoir les
modifications faites dans la base de registre et dans les fichiers
systèmes. Or la restauration à une date antérieure va supprimer l es
modifications de la base de données et des fichiers systèmes sans
replacer les fichiers de l'ancienne version. On se retrouve donc avec
des fichiers d'une nouvelle version avec une base et des fichiers
systèmes correspondants à l'ancienne. Vrai, faux ?
Ta mise à jour va être simplement annulée, c'est l'intérêt s i la MàJ de
ton logiciel s'est mal passée.
Mais attention à la date indiquée pour ton point de restauration !
S'il est ancien il y a bcp de modifications systèmes qui vont
disparaitre avec.
En général quand une mise à jour est bien faite elle réalise d ans son
package le point de restauration.
Si ce n'est pas le cas il est prudent de le faire manuellement sois-mê me
avant.
Donc vérifie cette date en priorité avant de faire quoi que ce soi t,
Tu as raison, il faut aller chercher le point le plus proche possible.j'ai vue des points de restauration dater de la mise en service du pc !
Si si ...
Cordialement.
Pierre
Le 15/11/2011 11:37, Zork a écrit :
"ChP"Supposons que la mise à jour du logiciel (dont je pense qu'elle est la
source de mes ennuis) ait modifié des entrées dans la base de registre
et ait créé/modifié des fichiers systèmes.
Oui.Faire une restauration à un point antérieur va, je pense, reprendre la
base de registre à un état antécédent, donc supprimer les nouvelles
entrées.
Oui
Je suppose que cette restauration va aussi rétablir/supprimerla création/modification des fichiers systèmes.
Oui
Dans ces condition, lamise à jour de mon logiciel va devenir complètement boîteuse.
Non
Je ne vois pas comment elle ne pourrait pas être boîteuse. Mon
raisonnement :
Après la mise à jour, les fichiers de l'ancienne version n'existent plus
(je ne pense pas que le processus de restauration se charge de stocker
les anciens fichiers) et les nouveaux nécessitent d'avoir les
modifications faites dans la base de registre et dans les fichiers
systèmes. Or la restauration à une date antérieure va supprimer les
modifications de la base de données et des fichiers systèmes sans
replacer les fichiers de l'ancienne version. On se retrouve donc avec
des fichiers d'une nouvelle version avec une base et des fichiers
systèmes correspondants à l'ancienne. Vrai, faux ?
Ta mise à jour va être simplement annulée, c'est l'intérêt si la MàJ de
ton logiciel s'est mal passée.
Mais attention à la date indiquée pour ton point de restauration !
S'il est ancien il y a bcp de modifications systèmes qui vont
disparaitre avec.
En général quand une mise à jour est bien faite elle réalise dans son
package le point de restauration.
Si ce n'est pas le cas il est prudent de le faire manuellement sois-même
avant.
Donc vérifie cette date en priorité avant de faire quoi que ce soit,
Tu as raison, il faut aller chercher le point le plus proche possible.j'ai vue des points de restauration dater de la mise en service du pc !
Si si ...
Cordialement.
Pierre
Le 15/11/2011 11:37, Zork a écrit :
"ChP"
Supposons que la mise à jour du logiciel (dont je pense qu'elle est la
source de mes ennuis) ait modifié des entrées dans la base de registre
et ait créé/modifié des fichiers systèmes.
Oui.
Faire une restauration à un point antérieur va, je pense, reprendre la
base de registre à un état antécédent, donc supprimer les nouvelles
entrées.
Oui
Je suppose que cette restauration va aussi rétablir/supprimer
la création/modification des fichiers systèmes.
Oui
Dans ces condition, la
mise à jour de mon logiciel va devenir complètement boîteuse.
Non
Je ne vois pas comment elle ne pourrait pas être boîteuse. Mon
raisonnement :
Après la mise à jour, les fichiers de l'ancienne version n'existent plus
(je ne pense pas que le processus de restauration se charge de stocker
les anciens fichiers) et les nouveaux nécessitent d'avoir les
modifications faites dans la base de registre et dans les fichiers
systèmes. Or la restauration à une date antérieure va supprimer les
modifications de la base de données et des fichiers systèmes sans
replacer les fichiers de l'ancienne version. On se retrouve donc avec
des fichiers d'une nouvelle version avec une base et des fichiers
systèmes correspondants à l'ancienne. Vrai, faux ?
Ta mise à jour va être simplement annulée, c'est l'intérêt si la MàJ de
ton logiciel s'est mal passée.
Mais attention à la date indiquée pour ton point de restauration !
S'il est ancien il y a bcp de modifications systèmes qui vont
disparaitre avec.
En général quand une mise à jour est bien faite elle réalise dans son
package le point de restauration.
Si ce n'est pas le cas il est prudent de le faire manuellement sois-même
avant.
Donc vérifie cette date en priorité avant de faire quoi que ce soit,
Tu as raison, il faut aller chercher le point le plus proche possible.
j'ai vue des points de restauration dater de la mise en service du pc !
Si si ...
Cordialement.
Pierre
Le 15/11/2011 11:37, Zork a écrit :
"ChP"Supposons que la mise à jour du logiciel (dont je pense qu'elle est la
source de mes ennuis) ait modifié des entrées dans la base de registre
et ait créé/modifié des fichiers systèmes.
Oui.Faire une restauration à un point antérieur va, je pense, reprendre la
base de registre à un état antécédent, donc supprimer les nouvelles
entrées.
Oui
Je suppose que cette restauration va aussi rétablir/supprimerla création/modification des fichiers systèmes.
Oui
Dans ces condition, lamise à jour de mon logiciel va devenir complètement boîteuse.
Non
Je ne vois pas comment elle ne pourrait pas être boîteuse. Mon
raisonnement :
Après la mise à jour, les fichiers de l'ancienne version n'existent plus
(je ne pense pas que le processus de restauration se charge de stocker
les anciens fichiers) et les nouveaux nécessitent d'avoir les
modifications faites dans la base de registre et dans les fichiers
systèmes. Or la restauration à une date antérieure va supprimer les
modifications de la base de données et des fichiers systèmes sans
replacer les fichiers de l'ancienne version. On se retrouve donc avec
des fichiers d'une nouvelle version avec une base et des fichiers
systèmes correspondants à l'ancienne. Vrai, faux ?
Ta mise à jour va être simplement annulée, c'est l'intérêt si la MàJ de
ton logiciel s'est mal passée.
Mais attention à la date indiquée pour ton point de restauration !
S'il est ancien il y a bcp de modifications systèmes qui vont
disparaitre avec.
En général quand une mise à jour est bien faite elle réalise dans son
package le point de restauration.
Si ce n'est pas le cas il est prudent de le faire manuellement sois-même
avant.
Donc vérifie cette date en priorité avant de faire quoi que ce soit,
Tu as raison, il faut aller chercher le point le plus proche possible.j'ai vue des points de restauration dater de la mise en service du pc !
Si si ...
Cordialement.
Pierre
Oui il a tranché, mais un peu trop fort dans le vif !
Son DD est peut-être scratché, et il ne peut plus te répondre pour le
moment.
Bon je dis ça, mais j'espère quand même me tromper.
:-)
Oui il a tranché, mais un peu trop fort dans le vif !
Son DD est peut-être scratché, et il ne peut plus te répondre pour le
moment.
Bon je dis ça, mais j'espère quand même me tromper.
:-)
Oui il a tranché, mais un peu trop fort dans le vif !
Son DD est peut-être scratché, et il ne peut plus te répondre pour le
moment.
Bon je dis ça, mais j'espère quand même me tromper.
:-)
Tonio le Yéti a écrit, le 15/11/2011 10:31 :La restauration attend que le taux de la TVA augmente... LOL
J'ai failli la faire, mais je n'osais pas avant que la question soit
résolue.
Tonio le Yéti a écrit, le 15/11/2011 10:31 :
La restauration attend que le taux de la TVA augmente... LOL
J'ai failli la faire, mais je n'osais pas avant que la question soit
résolue.
Tonio le Yéti a écrit, le 15/11/2011 10:31 :La restauration attend que le taux de la TVA augmente... LOL
J'ai failli la faire, mais je n'osais pas avant que la question soit
résolue.
Le 21/11/2011 19:13, Bernard Lempel a écrit :Oui il a tranché, mais un peu trop fort dans le vif !
Son DD est peut-être scratché, et il ne peut plus te répondre po ur le
moment.
Allez, même si mon DD était scratché, je pourrais venir vous cher cher à
mon aide, car j'ai une deuxième PC (celui de mon épouse) qui est en
bonne santé (l'épouse et le PC).Bon je dis ça, mais j'espère quand même me tromper.
:-)
Ton espoir est bon, mon disque dur tourne toujours et, consultant tous
les jours les évènements système, je n'ai eu qu'une erreur, aujou rd'hui
d'ailleurs : "atapi; ID 9 : Le périphérique DeviceIdeIdePort2 n' a pas
répondu dans le délai imparti."
J'ai supprimé l'anti-virus, le pare-feu (c'est celui de Windows qui a
pris le relai), j'ai défragmenté (cette action sur les temps de
chargement n'a strictement rien changé)
A ce jour, le démarrage est redevenu plus rapide pour la partie
postérieure à l'écran bleu "Bienvenue". A l'extinction, la partie
"enregistrement des données" est passée de 2 ou 3 minutes à quelq ues
secondes.
Pour autant, le premier chargement du disque vers la mémoire vive au
lancement d'une application est d'une longueur anormale. Comme je l'ai
déjà dit précédemment, le test S.M.A.R.T. m'indique un état d e santé de
mon disque C: de 100 % !!!
Le problème de l'image est que vue les performances de transaction du
disque, ce n'est pas une ou deux heures, mais très certainement plus de
24 h que je vais y passer. Dans ces conditions, ce que je me propose de
faire à plus ou moins court terme est de cloner mon disque C: et de l e
remplacer par son clone.
Mais quand même, tous les indicateurs sont actuellement au vert et je ne
m'explique pas ces énormes temps de transfert.
Cordialement.
Pierre
Le 21/11/2011 19:13, Bernard Lempel a écrit :
Oui il a tranché, mais un peu trop fort dans le vif !
Son DD est peut-être scratché, et il ne peut plus te répondre po ur le
moment.
Allez, même si mon DD était scratché, je pourrais venir vous cher cher à
mon aide, car j'ai une deuxième PC (celui de mon épouse) qui est en
bonne santé (l'épouse et le PC).
Bon je dis ça, mais j'espère quand même me tromper.
:-)
Ton espoir est bon, mon disque dur tourne toujours et, consultant tous
les jours les évènements système, je n'ai eu qu'une erreur, aujou rd'hui
d'ailleurs : "atapi; ID 9 : Le périphérique DeviceIdeIdePort2 n' a pas
répondu dans le délai imparti."
J'ai supprimé l'anti-virus, le pare-feu (c'est celui de Windows qui a
pris le relai), j'ai défragmenté (cette action sur les temps de
chargement n'a strictement rien changé)
A ce jour, le démarrage est redevenu plus rapide pour la partie
postérieure à l'écran bleu "Bienvenue". A l'extinction, la partie
"enregistrement des données" est passée de 2 ou 3 minutes à quelq ues
secondes.
Pour autant, le premier chargement du disque vers la mémoire vive au
lancement d'une application est d'une longueur anormale. Comme je l'ai
déjà dit précédemment, le test S.M.A.R.T. m'indique un état d e santé de
mon disque C: de 100 % !!!
Le problème de l'image est que vue les performances de transaction du
disque, ce n'est pas une ou deux heures, mais très certainement plus de
24 h que je vais y passer. Dans ces conditions, ce que je me propose de
faire à plus ou moins court terme est de cloner mon disque C: et de l e
remplacer par son clone.
Mais quand même, tous les indicateurs sont actuellement au vert et je ne
m'explique pas ces énormes temps de transfert.
Cordialement.
Pierre
Le 21/11/2011 19:13, Bernard Lempel a écrit :Oui il a tranché, mais un peu trop fort dans le vif !
Son DD est peut-être scratché, et il ne peut plus te répondre po ur le
moment.
Allez, même si mon DD était scratché, je pourrais venir vous cher cher à
mon aide, car j'ai une deuxième PC (celui de mon épouse) qui est en
bonne santé (l'épouse et le PC).Bon je dis ça, mais j'espère quand même me tromper.
:-)
Ton espoir est bon, mon disque dur tourne toujours et, consultant tous
les jours les évènements système, je n'ai eu qu'une erreur, aujou rd'hui
d'ailleurs : "atapi; ID 9 : Le périphérique DeviceIdeIdePort2 n' a pas
répondu dans le délai imparti."
J'ai supprimé l'anti-virus, le pare-feu (c'est celui de Windows qui a
pris le relai), j'ai défragmenté (cette action sur les temps de
chargement n'a strictement rien changé)
A ce jour, le démarrage est redevenu plus rapide pour la partie
postérieure à l'écran bleu "Bienvenue". A l'extinction, la partie
"enregistrement des données" est passée de 2 ou 3 minutes à quelq ues
secondes.
Pour autant, le premier chargement du disque vers la mémoire vive au
lancement d'une application est d'une longueur anormale. Comme je l'ai
déjà dit précédemment, le test S.M.A.R.T. m'indique un état d e santé de
mon disque C: de 100 % !!!
Le problème de l'image est que vue les performances de transaction du
disque, ce n'est pas une ou deux heures, mais très certainement plus de
24 h que je vais y passer. Dans ces conditions, ce que je me propose de
faire à plus ou moins court terme est de cloner mon disque C: et de l e
remplacer par son clone.
Mais quand même, tous les indicateurs sont actuellement au vert et je ne
m'explique pas ces énormes temps de transfert.
Cordialement.
Pierre
ChP a écrit, le 21/11/2011 23:35 :Le 21/11/2011 19:13, Bernard Lempel a écrit :Oui il a tranché, mais un peu trop fort dans le vif !
Son DD est peut-être scratché, et il ne peut plus te répondre pour le
moment.
Allez, même si mon DD était scratché, je pourrais venir vous chercher à
mon aide, car j'ai une deuxième PC (celui de mon épouse) qui est en
bonne santé (l'épouse et le PC).Bon je dis ça, mais j'espère quand même me tromper.
:-)
Ton espoir est bon, mon disque dur tourne toujours et, consultant tous
les jours les évènements système, je n'ai eu qu'une erreur, aujourd'hui
d'ailleurs : "atapi; ID 9 : Le périphérique DeviceIdeIdePort2 n'a pas
répondu dans le délai imparti."
J'ai supprimé l'anti-virus, le pare-feu (c'est celui de Windows qui a
pris le relai), j'ai défragmenté (cette action sur les temps de
chargement n'a strictement rien changé)
A ce jour, le démarrage est redevenu plus rapide pour la partie
postérieure à l'écran bleu "Bienvenue". A l'extinction, la partie
"enregistrement des données" est passée de 2 ou 3 minutes à quelques
secondes.
Pour autant, le premier chargement du disque vers la mémoire vive au
lancement d'une application est d'une longueur anormale. Comme je l'ai
déjà dit précédemment, le test S.M.A.R.T. m'indique un état de santé de
mon disque C: de 100 % !!!
Le problème de l'image est que vue les performances de transaction du
disque, ce n'est pas une ou deux heures, mais très certainement plus de
24 h que je vais y passer. Dans ces conditions, ce que je me propose de
faire à plus ou moins court terme est de cloner mon disque C: et de le
remplacer par son clone.
Mais quand même, tous les indicateurs sont actuellement au vert et je ne
m'explique pas ces énormes temps de transfert.
Cordialement.
Pierre
Au moins, si ça fait pareil, le disque ne sera pas en cause.
ChP a écrit, le 21/11/2011 23:35 :
Le 21/11/2011 19:13, Bernard Lempel a écrit :
Oui il a tranché, mais un peu trop fort dans le vif !
Son DD est peut-être scratché, et il ne peut plus te répondre pour le
moment.
Allez, même si mon DD était scratché, je pourrais venir vous chercher à
mon aide, car j'ai une deuxième PC (celui de mon épouse) qui est en
bonne santé (l'épouse et le PC).
Bon je dis ça, mais j'espère quand même me tromper.
:-)
Ton espoir est bon, mon disque dur tourne toujours et, consultant tous
les jours les évènements système, je n'ai eu qu'une erreur, aujourd'hui
d'ailleurs : "atapi; ID 9 : Le périphérique DeviceIdeIdePort2 n'a pas
répondu dans le délai imparti."
J'ai supprimé l'anti-virus, le pare-feu (c'est celui de Windows qui a
pris le relai), j'ai défragmenté (cette action sur les temps de
chargement n'a strictement rien changé)
A ce jour, le démarrage est redevenu plus rapide pour la partie
postérieure à l'écran bleu "Bienvenue". A l'extinction, la partie
"enregistrement des données" est passée de 2 ou 3 minutes à quelques
secondes.
Pour autant, le premier chargement du disque vers la mémoire vive au
lancement d'une application est d'une longueur anormale. Comme je l'ai
déjà dit précédemment, le test S.M.A.R.T. m'indique un état de santé de
mon disque C: de 100 % !!!
Le problème de l'image est que vue les performances de transaction du
disque, ce n'est pas une ou deux heures, mais très certainement plus de
24 h que je vais y passer. Dans ces conditions, ce que je me propose de
faire à plus ou moins court terme est de cloner mon disque C: et de le
remplacer par son clone.
Mais quand même, tous les indicateurs sont actuellement au vert et je ne
m'explique pas ces énormes temps de transfert.
Cordialement.
Pierre
Au moins, si ça fait pareil, le disque ne sera pas en cause.
ChP a écrit, le 21/11/2011 23:35 :Le 21/11/2011 19:13, Bernard Lempel a écrit :Oui il a tranché, mais un peu trop fort dans le vif !
Son DD est peut-être scratché, et il ne peut plus te répondre pour le
moment.
Allez, même si mon DD était scratché, je pourrais venir vous chercher à
mon aide, car j'ai une deuxième PC (celui de mon épouse) qui est en
bonne santé (l'épouse et le PC).Bon je dis ça, mais j'espère quand même me tromper.
:-)
Ton espoir est bon, mon disque dur tourne toujours et, consultant tous
les jours les évènements système, je n'ai eu qu'une erreur, aujourd'hui
d'ailleurs : "atapi; ID 9 : Le périphérique DeviceIdeIdePort2 n'a pas
répondu dans le délai imparti."
J'ai supprimé l'anti-virus, le pare-feu (c'est celui de Windows qui a
pris le relai), j'ai défragmenté (cette action sur les temps de
chargement n'a strictement rien changé)
A ce jour, le démarrage est redevenu plus rapide pour la partie
postérieure à l'écran bleu "Bienvenue". A l'extinction, la partie
"enregistrement des données" est passée de 2 ou 3 minutes à quelques
secondes.
Pour autant, le premier chargement du disque vers la mémoire vive au
lancement d'une application est d'une longueur anormale. Comme je l'ai
déjà dit précédemment, le test S.M.A.R.T. m'indique un état de santé de
mon disque C: de 100 % !!!
Le problème de l'image est que vue les performances de transaction du
disque, ce n'est pas une ou deux heures, mais très certainement plus de
24 h que je vais y passer. Dans ces conditions, ce que je me propose de
faire à plus ou moins court terme est de cloner mon disque C: et de le
remplacer par son clone.
Mais quand même, tous les indicateurs sont actuellement au vert et je ne
m'explique pas ces énormes temps de transfert.
Cordialement.
Pierre
Au moins, si ça fait pareil, le disque ne sera pas en cause.
Une question que je me pose, n'y a-t-il pas un option qui, lors des
copies sur disque, permet ou non une vérification de la copie.
L'activation de cette option ralentissant les opérations ?
Si cette option existe, n'agit-elle pas lors de swap ?
Et toujours, si elle existe, où la gère-t-on ?
Cordialement.
Pierre.
Une question que je me pose, n'y a-t-il pas un option qui, lors des
copies sur disque, permet ou non une vérification de la copie.
L'activation de cette option ralentissant les opérations ?
Si cette option existe, n'agit-elle pas lors de swap ?
Et toujours, si elle existe, où la gère-t-on ?
Cordialement.
Pierre.
Une question que je me pose, n'y a-t-il pas un option qui, lors des
copies sur disque, permet ou non une vérification de la copie.
L'activation de cette option ralentissant les opérations ?
Si cette option existe, n'agit-elle pas lors de swap ?
Et toujours, si elle existe, où la gère-t-on ?
Cordialement.
Pierre.
ChP a écrit, le 22/11/2011 09:32 :Une question que je me pose, n'y a-t-il pas un option qui, lors des
copies sur disque, permet ou non une vérification de la copie.
L'activation de cette option ralentissant les opérations ?
Si cette option existe, n'agit-elle pas lors de swap ?
Et toujours, si elle existe, où la gère-t-on ?
Cordialement.
Pierre.
Avec la commande COPY du DOS, il y avait l'option /V.
Avec les logiciels de sauvegarde actuels, c'est effectivement une bonne
question. De temps à autre, est ouvert un fil sur le choix d'un logic iel
de sauvegarde. Je soulève la question de la comparaison de la cible a vec
la source, mais sans grand écho.
XCOPY a aussi une option de vérification, qui vérifie juste, comme pour
COPY /V, qu'il n'y a pas eu une erreur intrinsèque d'écriture. Pour
garder trace, sur toute une sauvegarde, d'une erreur de sauvegarde (par
exemple, un fichier n'a pas pu être copié car il était verrouillé ), il y
a XXCOPY, qui est très proche et ajoute des options. J'imagine que
comparer la cible à la source serait une opération à mener à pa rt. Au
moins si une erreur intrinsèque est signalée, ça limite déjà les dégâts.
Quand j'ai commencé à soulever cette question j'utilisais Ghost 200 3.
Avec ça, en fouillant bien dans l'aide on trouve une option pour
inscrire dans un journal les sommes MD5 des fichiers sauvegardés. En
écrivant un script pour ça on devrait pouvoir les comparer aux somm es
MD5 des fichiers sources. J'ignore si depuis le traitement a été fo urni
de manière "Michu-compliant".
ChP a écrit, le 22/11/2011 09:32 :
Une question que je me pose, n'y a-t-il pas un option qui, lors des
copies sur disque, permet ou non une vérification de la copie.
L'activation de cette option ralentissant les opérations ?
Si cette option existe, n'agit-elle pas lors de swap ?
Et toujours, si elle existe, où la gère-t-on ?
Cordialement.
Pierre.
Avec la commande COPY du DOS, il y avait l'option /V.
Avec les logiciels de sauvegarde actuels, c'est effectivement une bonne
question. De temps à autre, est ouvert un fil sur le choix d'un logic iel
de sauvegarde. Je soulève la question de la comparaison de la cible a vec
la source, mais sans grand écho.
XCOPY a aussi une option de vérification, qui vérifie juste, comme pour
COPY /V, qu'il n'y a pas eu une erreur intrinsèque d'écriture. Pour
garder trace, sur toute une sauvegarde, d'une erreur de sauvegarde (par
exemple, un fichier n'a pas pu être copié car il était verrouillé ), il y
a XXCOPY, qui est très proche et ajoute des options. J'imagine que
comparer la cible à la source serait une opération à mener à pa rt. Au
moins si une erreur intrinsèque est signalée, ça limite déjà les dégâts.
Quand j'ai commencé à soulever cette question j'utilisais Ghost 200 3.
Avec ça, en fouillant bien dans l'aide on trouve une option pour
inscrire dans un journal les sommes MD5 des fichiers sauvegardés. En
écrivant un script pour ça on devrait pouvoir les comparer aux somm es
MD5 des fichiers sources. J'ignore si depuis le traitement a été fo urni
de manière "Michu-compliant".
ChP a écrit, le 22/11/2011 09:32 :Une question que je me pose, n'y a-t-il pas un option qui, lors des
copies sur disque, permet ou non une vérification de la copie.
L'activation de cette option ralentissant les opérations ?
Si cette option existe, n'agit-elle pas lors de swap ?
Et toujours, si elle existe, où la gère-t-on ?
Cordialement.
Pierre.
Avec la commande COPY du DOS, il y avait l'option /V.
Avec les logiciels de sauvegarde actuels, c'est effectivement une bonne
question. De temps à autre, est ouvert un fil sur le choix d'un logic iel
de sauvegarde. Je soulève la question de la comparaison de la cible a vec
la source, mais sans grand écho.
XCOPY a aussi une option de vérification, qui vérifie juste, comme pour
COPY /V, qu'il n'y a pas eu une erreur intrinsèque d'écriture. Pour
garder trace, sur toute une sauvegarde, d'une erreur de sauvegarde (par
exemple, un fichier n'a pas pu être copié car il était verrouillé ), il y
a XXCOPY, qui est très proche et ajoute des options. J'imagine que
comparer la cible à la source serait une opération à mener à pa rt. Au
moins si une erreur intrinsèque est signalée, ça limite déjà les dégâts.
Quand j'ai commencé à soulever cette question j'utilisais Ghost 200 3.
Avec ça, en fouillant bien dans l'aide on trouve une option pour
inscrire dans un journal les sommes MD5 des fichiers sauvegardés. En
écrivant un script pour ça on devrait pouvoir les comparer aux somm es
MD5 des fichiers sources. J'ignore si depuis le traitement a été fo urni
de manière "Michu-compliant".