XCOPY : mémoire manquante

Le
Gloops
Bonjour tout le monde,

Pour transférer des fichiers d'un portable Windows XP à un autre
portable Windows XP (SP1 pour le premier, SP2 pour le deuxième), j'ai
utilisé XCOPY, vers un disque externe dans le premier cas, depuis le
disque externe dans le deuxième cas.

Dans le premier cas, une fois qu'on a enfin réussi à faire reconnaître
le disque externe par la machine et à éviter de le planter en voulant le
relire (il fallait bien une raison pour se procurer une autre machine
alors que la première, de chez Samsung, est toujours sous garantie), le
transfert se passe bien, c'est d'ailleurs une manoeuvre courante.

Dans le deuxième cas, on copie une centaine de fichiers, plutôt vite
d'ailleurs, et puis on s'arrête net, et on se plaint qu'on n'a pas assez
de mémoire pour travailler.

Physiquement, la première machine propose 256 Mo de mémoire, la deuxième
512 Mo. Donc 512 Mo ne suffit pas à faire ce qu'on a fait sans problème
avec 256 Mo. J'ai quand même parlé un peu vite, l'utilisation de la
mémoire est par ailleurs plus généreuse sur le deuxième portable, ce qui
fait qu'il en reste moins, tel que déclaré par msinfo32 (physique
disponible 99,35 Mo sur le premier, 63,58 Mo sur le deuxième ; en
revanche mémoire virtuelle disponible 386,60 Mo sur le premier, 1,96 Go
sur le deuxième -même pas la même unité. ça varie un petit poil d'une
mesure à l'autre.

Dans tous les cas, sur les deux machines, dans la fenêtre de lignes de
commandes, MEM m'affiche la même chose :



655360 octets de mémoire conventionelle
655360 octets disponibles pour MS-DOS
588400 taille maximale du programme exécutable

1048576 octets de mémoire étendue contiguë
1048576 octets disponibles de mémoire étendue contiguë
941056 octets disponibles de mémoire XMS
MS-DOS résident en mémoire haute (HMA)


N'est-ce pas cela qui compte ?

J'ai regardé CONFIG.NT et AUTOEXEC.NT, pas de différence notable. Au
contraire, dans le deuxième cas on ne déclare pas Java et ANSI.SYS, donc
si je ne m'abuse ça devrait libérer d'autant plus de mémoire.

Je n'ai pas vu de différence notable non plus dans les raccourcis de
lancement de CMD.EXE

Pour ma part, je trouve que c'est une histoire à dormir debout, j'espère
que quelqu'un y verra plus clair que moi

Il me semble que c'est dans les propriétés du raccourci qu'on précise si
on veut utiliser d'autres fichiers à la place de CONFIG.NT et
AUTOEXEC.NT, je ne sais plus au juste où. Peut-être une piste ?

C:WINDOWSSYSTEM32CONFIG.NT :
dos=high, umb
device=%SystemRoot%system32himem.sys /INT1524
files@
DEVICE=%SystemRoot%system32ansi.sys

Par rapport à ce qu'il y avait sur la deuxième machine j'ai ajouté
/INT1524 et la ligne ansi.sys, qui n'y étaient pas, pour me conformer
à la première machine. C'est ce qui s'appelle copier bêtement, car je
crois bien que ANSI.SYS n'est pas reconnu par CMD.EXE, seulement COMMAND.COM

Bien sûr je vous fais grâce des lignes en commentaire.

C:WINDOWSSYSTEM32AUTOEXEC.NT :
@echo off
lh %SystemRoot%system32mscdexnt.exe
lh %SystemRoot%system32edir
lh %SystemRoot%system32dosx
SET BLASTER20 I5 D1 P330 T3

Cette dernière ligne n'est pas sur la première machine. Je l'ai mise en
commentaire, pas de changement.

J'ai essayé dans une fenêtre de CMD.EXE et dans une de COMMAND.COM

J'ai fait une tentative en lignes de commandes en mode sans échec,
pareil. Encore plus perturbant, non ?
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
JF
Le #1424056
*Bonjour Gloops* ! Tu disais, dans le message
news:

| Bonjour tout le monde,
|
| Pour transférer des fichiers d'un portable Windows XP à un autre
| portable Windows XP (SP1 pour le premier, SP2 pour le deuxième), j'ai
| utilisé XCOPY, vers un disque externe dans le premier cas, depuis le
| disque externe dans le deuxième cas.
|
| Dans le premier cas, une fois qu'on a enfin réussi à faire reconnaître
| le disque externe par la machine et à éviter de le planter en voulant
le
| relire (il fallait bien une raison pour se procurer une autre machine
| alors que la première, de chez Samsung, est toujours sous garantie),
le
| transfert se passe bien, c'est d'ailleurs une manoeuvre courante.
|
| Dans le deuxième cas, on copie une centaine de fichiers, plutôt vite
| d'ailleurs, et puis on s'arrête net, et on se plaint qu'on n'a pas
assez
| de mémoire pour travailler.

Robocopy remplace avantageusement xcopy:
www.gratilog.net/reseau1.htm#robocopy
Tu n'auras peut-être plus ces problèmes de mémoire avec cet outil ?
Sinon, j'espère que quelqu'un a une réponse moins lâche que la mienne:o)
--
1- Salutations, Jean-François :o)
2- Index du site de PN : www.d2i.ch/pn/az
3- Montrez vos copies d'écrans http://cjoint.com ou www.imageshack.us
4- Outlook Express: Suivez vos fils avec [CTL+H]
Gloops
Le #1424044
Salut,

J'avoue que ça m'intrigue bien que XCOPY qui me fait mes sauvegardes
sans broncher depuis quelques mois tique maintenant que j'ai une machine
qui ne se bat pas avec les disques externes (vrai, quoi, on n'a pas idée
de confondre un disque dur avec un casse-croûte).

A part ça, cette affaire est tellement bizarre qu'il ne faut pas exclure
d'avance que personne n'ait de réponse hélas.

Alors après tout, si il y a un truc tout prêt, ça mérite sûrement un
coup d'oeil.

Merci.
____________
Robocopy remplace avantageusement xcopy:
www.gratilog.net/reseau1.htm#robocopy
Tu n'auras peut-être plus ces problèmes de mémoire avec cet outil ?
Sinon, j'espère que quelqu'un a une réponse moins lâche que la mienne:o)


Gloops
Le #1424015
Bon, eh bien voilà, c'est fait.

Alors au passage, j'ai pu m'apercevoir que tant que je demandais à
copier depuis la racine du disque externe, rien à faire, ça ne passe
pas. Le glissé de souris dans l'explorateur me dit "impossible de copier
le fichier :"

J'ai un fichier qui s'appelle comme ça, moi ?

XCOPY copie une centaine de fichiers, et manque de mémoire.

Robocopy effectue 23 tentatives de copies espacées de 30 secondes, le
tout en une demi-seconde, à la suite de quoi il n'y a rien dans le
répertoire cible.

Alors, j'ai indiqué comme source le répertoire contenant la sauvegarde.
Je voulais qu'il soit créé sur la cible, c'est pour ça que j'indiquais
la racine -en me référant aux syntaxes patiemment apprises sous ... DOS
3.3O.

Eh bien le répertoire a bien été créé dans la cible.

Au passage, je me suis aperçu que Robocopy annonce pouvoir
"synchroniser" des répertoires, c'est-à-dire effacer dans la cible les
fichiers qui ont été effacés dans la source. Il me semble bien que qu'on
m'avait parlé de Robocopy, un jour, et ce point a dû m'échapper. Pour
les copies, XCOPY me paraissait tellement simple une fois que j'avais
découvert l'option /C (à savoir que le premier fichier peut être
verrouillé, ça n'empêche pas de copier les 18427 suivants).

Finalement, un seul défaut : Robocopy génère un rapport en caractères
OEM, et l'ouvre dans un éditeur qui affiche des caractères ANSI, donc
les e accent aigu sont transformés en virgule. Enfin on comprend quand
même de quoi il retourne.

ça va m'éviter d'avoir à écrire un filtre en assembleur, pour garder un
compte-rendu des copies faites par XCOPY -vu qu'à ma connaissance si on
redirige la sortie vers un fichier on ne voit rien à l'écran.

Voilà un essai qui me paraît concluant.


Robocopy remplace avantageusement xcopy:
www.gratilog.net/reseau1.htm#robocopy
Tu n'auras peut-être plus ces problèmes de mémoire avec cet outil ?
Sinon, j'espère que quelqu'un a une réponse moins lâche que la mienne:o)


Poster une réponse
Anonyme