Si kkun arrive à m’expliquer.

[Rafo]

Rafo

#864

Salut, voici le casse-tête du jour.

Voici un copier/coller de ce que j’ai fait sur le shell, sans aucune

retouche, hormis quelques sauts de lignes, pour garder un minimum de

lisibilité, je pense pas avoir besoin de détailler :

— start quote

Ram Disk:MorphVNC> copy MorphVNC c:

Ram Disk:MorphVNC> list c:MorphVNC

Directory « c: » on Lundi 25-Oct-04

MorphVNC 79468 —-rwed Aujourd’hui 02:50:15

1 file – 79468 bytes used

Ram Disk:MorphVNC> list MorphVNC

MorphVNC 79468 —-rwed 10-Jan-04 21:58:58

1 file – 79468 bytes used

Ram Disk:MorphVNC> version MorphVNC

MorphVNC 1.3

Ram Disk:MorphVNC> version c:MorphVNC

Could not find version information for ‘c:MorphVNC’

Ram Disk:MorphVNC> MorphVNC 192.168.1.7

Connecting to ‘192.168.1.7’ port 5900

Server supports RFB protocol version 3.8

Authentication needed

Login succesful

Desktopname: GROPQ

Server preferred settings:

Depth: 16 BPP: 16

big_endian: 0

truecolor: 1

RGB shift: 11 5 0

RGB max: 31 63 31

Settings sent to server:

Depth: 16 BPP: 16

big_endian: 1

truecolor: 1

RGB shift: 11 5 0

RGB max: 31 63 31

Depth: 16

Did 172 updates

Statistics:

Encoding | Rectangles | pixels/byte

---

+

---

+

---

Raw | 14 | 0.50

Copyrect | 0 | NaN

RRE | 13 | 9.58

CORRE | 0 | NaN

ZLib | 0 | NaN

Ram Disk:MorphVNC> c:MorphVNC 192.168.1.7

c:MorphVNC: file is not executable

Ram Disk:MorphVNC>

— end quote

Bon, pour les nuls et les non entravants, je résume.

J’ai downloadé l’archive de MorphVNC que j’ai désarchivé vers RAM:

j’ai ensuite copié le fichier MorphVNC vers C:

les deux LIST permettent de se rendre compte que les deux fichiers ont

exactement la même taille.

par contre, un VERSION sur celui en RAM: donne bien la version, mais

un VERSION sur celui copié sur le disque dur ne donne rien du tout.

Et surtout, celui en RAM s’exécute normalement alors que celui sur

disque dur est un « fichier non exécutable ».

Deuxième exemple :

— start quote

Ram Disk:> copy MOSSYS:C/Copy ram:

Ram Disk:> copy ram:copy c:

Ram Disk:> ram:copy

wrong number of arguments

Ram Disk:> c:copy

c:copy: file is not executable

Ram Disk:>

— end quote

j’ai ensuite créé 2 archives avec le même programme lha, l’une avec le

COPY situé dans RAM:, l’autre avec celui sur C:

voici les résultats :

http://rafo.free.fr/mos/copyram.lha

http://rafo.free.fr/mos/copyc.lha

le fichier original tel que situé dans RAM::

http://rafo.free.fr/mos/Copy

Déjà, les tailles des archives sont différentes, ce qui est quand même

pas mal suspect, alors que l’exécutable lui est de la même taille.

Qu’a-t-il bien pu se passer ? aucune idée.

Un désarchivage de copyram.lha vers C: produit le même résultat quand

on lance C:Copy : fichier non exécutable.

Bref, il semblerait que tout fichier, du moins exécutable, que je

copie sur cette partition soit définitivement trashé.

J’avoue ne pas comprendre ce qui se passe, ni pourquoi.

Alors comme le dit le topic, si kkun a une explication.

Je précise, pour couper court à quelques questions qui ne manqueront

pas de traverser quelques esprits, que la partition système est en

SFS, comme elle l’a toujours été sur le Peg. Ce n’est pas la partition

sur laquelle se trouve l’image de boot, laquelle est indépendante, en

FFS et non mountée sur Ambient.

Si kkun a déjà eu ce genre de problème et l’a déjà résolu, je suis

preneur.

je viens d’essayer la même opérations sur la partoche applications,

j’ai eu exactement les mêmes résultats.

Par contre, si je fais pareil avec la partition Video: tout se passe

bien et je peux exécuter sans problème.

Point commun entre Systeme: et Applications:, elles ont été

fraîchement formatées, ce qui n’est pas le cas de Video:

Le formatage a été fait avec Utilities/Format Disk d’Ambient, et je

dois dire que ça m’a donné l’occasion de remarquer une anomalie

intéressante :

FORMAT+VERIFY ne produit absolument aucun effet. En effet (sic),

si je formate la partoche système avec ce bouton et que je reboote, le

contenu est toujours là et fonctionne.

J’ai donc formaté avec « Quick Format » et là c’était bon. Seulement

voilà, j’obtiens après cela les résultats que je viens de décrire.

J’ai répété l’opération en formatant depuis le boot sur CD, idem.

[anonyme]

anonyme

#23510

Heu… C’est absolument fantastique ton truc.

Plus sèrieusement, le point commun a tous tes exemples, c’est l’instruction Copy. As tu tenté en repiquant (pour test uniquement) la commande C:Copy d’AmigaOs 68k? Ou encore en te faisant refourguer un autre Copy natif par un autre Morphiste.

Je sais, tu vas me dire que Copy marchait avant, et que y’a pas de raison. Mais ça marche toujours avant d’exploser.

EDIT: Je sens d’ici venir la reflexion qui vas gonfler Rafo alors j’anticipe pour lui: NON, rafo n’est pas con d’avoir envie d’utiliser le Shell alors qu’on peut le faire sur le bureau (enfin, ça dépend du bureau), oui, Rafo fait comme il veux.

[Rafo]

Rafo

#23511

Ben, en fait, je fais mes copies de fichiers avec Ambient en général,

mais j’ai commencé à noter des trucs zarb, genre je copie un fichier,

puis au reboot, il est plus là. Alors bon le shell permet quand même

de savoir ce qui se passe (à défaut de comprendre pourquoi ça

arrive).

Sinon pour répondre à ta question, le fichier COPY original, toujours

situé dans MOSSYS:C/ fonctionne toujours. En fait, tout marche,

seulement, je ne peux rien écrire sur le disque. Certes à l’écran tout

se passe comme si la copie s’était bien passée (genre je déplace AmIRC

vers Système: j’ai bien l’icône qui apparaît, mais un double clic

dessus ne donne rien. un DIR sur Systeme: me donne bien l’icône, je

peux explorer le contenu du répertoire, mais un double-clic sur

l’icône du prog AmIRC ne produit rien du tout.

[Reboot]

et là….rien, plus de répertoire AmIRC dans systeme, disparu, envolé.

Comme s’il n’avait jamais été copié.

Alors bon j’ai pris copy comme exemple, c’était certes pas forcément

le plus parlant, mais j’obtiens des résultats similaires avec

n’importe quoi, répertoire, exécutable, bref, rien ne se copie du

tout.

Et devinez quoi ? le fichier « Copy » que j’avais copié vers C: ne s’y

trouve plus. Une fois rebooté, plus rien. Je l’ai pourtant archivé

dans un LhA comme le montre l’exemple que j’ai indiqué dans le premier

post. Certes le fichier est merdé, mais il n’empêche qu’il était bel

et bien présent. Et là, ben non il y est plus. En gros, c’est comme si

le disque était en read-only, sauf que ben j’ai aucun message

d’erreur, et que niveau système tout se passe comme si la copie

s’était passée normalement : sous Ambient les icônes sont bien

déplacées (une fermeture / réouverture de la fenêtre confirme), dans

le shell, un dir confirme la présence du fichier, mais une fois

rebooté, rien n’a bougé.

Cool, non ?

[seg]

seg

#23512

Salut Rafo,

Ben moi, j’ai pas de pegasos mais tout ca me rappelle des problemes de « max transfert » sur mon Amiga.

Si ca peut te donner une idee…

a+

Seb.

[thefab]

thefab

#23513

j’avoue que ce problème est assez étrange, et que je ne peut pas le reproduire ici (perso j’ai un problème d’un autre ordre, certaines archives lha qui refusent de se décompresser en ram alors qu’elles se décompressent bien sur une partoche)

[ACE]

ACE

#23514

Pour ma part Rafo je te recommande un logiciel du type Ecodisk II c’est super et franchement Ambient suxx pour la manip des fichiers ! Je pense que Mos aurait tout a gagner en ameliorant ce cote la !

Peu de gens qui ont mos s’amuse à copier avec ambient (tsé moi aussi au debut)

Mais bon j’ai copier des truc qui font O ko apres c nul

Vive Dopus ou Ecodisk II C de la balle ! Pour moi rien ne les vaut ! C simple c pas beau mais c redoutable et c ça qui compte des fois !

Au fait EcosdiskII est multitache tu peux lancer cinq copie en meme temps (c bien geek) il reconnais les filetype (ex:lancer snes9x si .smc etc..) C bien mieu que l’ambient actuel ou que l’os3.9 avec des deficons qui suxx la memoire et qui sont bizarre des fois. Mefin j’epere que Ambient va s’ameliorer et j’epere aussi pour Os4 car de ce cote la sur L’Os3.9 c’etait geek (genre tout ce que je vois pas multiview et pof ça plante meme les amigaguide c’etait fort ! Blizzppc rulez tres instable chez moi)

Le PSG qui gagne la ligue des champions c'est possible ... Que dans Swos.
Amiga Morphos Rules.

[Rafo]

Rafo

#23515

J’ai aussi EcodiskII, ça ne marche pas mieux. En fait, je ne pense

pas que ça soit la manière dont sont transférés les fichiers qui soit

en cause, je verrais plutôt une histoire de filesystem.

Quant à l’histoire du maxtransfer, il me semble que ça se règle dans

le prog de partitionnement, pas dans celui de formatage. Or seul le

formatage a eu lieu. A aucun moment je n’ai utilisé l’outil de

partitionnement (SCSIConfig).

Par contre, j’ai du nouveau : j’ai aussi copié l’exécutable de

MorphVNC depuis la RAM (d’où il se lance très bien) vers DATA: qui se

trouve physiquement sur le même disque dur que Systeme: et

Applications: mais qui n’a PAS ETE FORMATEE. et devinez quoi ? IDEM.

« Fichier non exécutable ».

Je commence à me demander si ce n’est pas, soit SFS qui pète les

plombs (mais cela me semble peu probable car la partition Video:,

située sur un autre disque, et utilisant aussi le SFS interne à MOS,

fonctionne très bien), soit carrément le disque dur lui-même (bien

plus difficile à diagnostiquer, car les lectures, elles, se font sans

problèmes, et pour cause, c’est dessus que se trouve le système, et je

suis dessus en ce moment).

SCSIConfig ne m’indique pas qu’un autre filesystem que celui interne à

MOS est utilisé, mais je ne sais pas si cette information est fiable.

En effet, le disque dur qui contient Systeme:, Applications:, et Data:

est le plus ancien et a déjà servi sur mon 1200 (et n’a posé aucun

problème depuis presque 2 ans que je l’utilise sur Peg).

Du coup je me demande commet on peut savoir quelle est la version de

SFS qui est utilisé sur telle ou telle partition ? Sur AmigaOS, une

commande genre « version DH0: » donnait « SmartFileSystem vX.YY » alors

que sous MOS, c’est « object not found ». Comme s’il lui fallait

absolument un fichier. Alors bon soit cette « feature » est absente de

al version MOS de « Version », soit il y a un autre moyen, mais que je

n’ai pas trouvé. Même « info verbose » ne permet pas de le savoir.

Bref (héhé), le problème reste posé et sa cause reste quasi-inconnue.

[OFFTOPIC]

Au passage, dans EcoDisk le truc qui me gène pas mal, c’est

l’impossibilité d’interrompre une copie une fois qu’elle est commencée

(pas de bouton ‘annuler’)

[/OFFTOPIC]

[BatteMan]

BatteMan

#23516

[OFFTOPIC]

Rafo : Tiens, moi j’ai un bouton STOP dans mon EcoDisk… sûrement une bidouille de Poly

Si tu veux, je dois avoir l’archive d’EcoDisk II Fr sur http://batteman.free.fr/ (elle y est plus… mais je peux la remettre).

—

/me est OT, mais c’est pour la bonne cause

[/OFFTOPIC]

Only Amiga makes it possible !

[anonyme]

anonyme

#23517

ha oui oui oui oui oui maintenant que j’y pense! Le coup des fichiers qui disparaissent, j’ai eu le meme coup que Rafo, c’était excessivement penible !!!

Maintenant je ne saurais plus dire si j’avais une solution, si c’était avant ou après MOS 1.4, de toute façon peu de temps après ça mon Peg s’est mis à reconnaitre mon 80 GB comme un 7 GB et c’est à ce moment là que j’ai abandonné et vous connaissez la suite.

Mais oui oui oui j’ai eu les meme soucis que Rafos……. mais je sais plus quoi faire. Courage !

PS: C’est un Western Digital le dur qui merde chez toi?

[Feuille]

Feuille

#23518

ArticiaRoxx a écrit des trucs…

Ah ! les rapports conflictuels entre Crisot et ses disques durs… On pourrait en faire un sacré bon roman ; reste à imaginer une cause à tout cela…

Au fait, ça prend combien de temps un formattage hard d’un disque dur de 80Go ?

Maison !(/b]
Bastringue Corp

[Rafo]

Rafo

#23519

PS: C’est un Western Digital le dur qui merde chez toi?

Non, c’est un Maxtor.

Alors le truc qui fait vraiment chier, c’est que ça s’est généralisé à tout type d’action. Par exemple les emails que je reçois. Bon, YAM les prend, je peux les lire, nickel. Reboot, paf ! ils sont plus là.

En gros, c’est comme si les fichiers étaient bel et bien écrits sur le disque, mais que la « FAT » n’était pas mise à jour sur le disque et que seul le « cache » soit mis à jour, et que SFS tape dans ce cache justement.

Je sais, ça n’a ni queue ni tête, mais c’est une supposition. Il suffit que je reboote pour que toutes les modifications apportées au disque ne soient plus là. Je modifie les prefs d’un programme, OK ça marche, mais au boot suivant, j’ai plus qu’à les refaire car c’est revenu dans l’état précédent.

Et encore, c’est sans parler du contenu plus ou moins trashé de ce qui est écrit sur le disque. Pour l’instant ça va, les e-mails fraîchement récupérés sont lisibles. Mais pour l’archivage, c’est moyen…

Un truc de ouf j’vous dis.

[CLS2086]

CLS2086

#23520

ça sent le verrouillage d’écriture ça.

Soit le cache du HDD, soit une merdouille de SFS

T’as pas une partoche FFS sur le même HDD pour vérifier ?

/corriger parce que thefab a pas fait l’effort de comprendre ce que j’ai écris trop vite

[thefab]

thefab

#23521

qu’est-ce que pfs3 vient faire là-dedans?

/me qui pense que CLS est encore à côté de la plaque

[anonyme]

anonyme

#23522

Au fait, ça prend combien de temps un formattage hard d’un disque dur de 80Go ?

??? J’ai toujours formattés mes durs en quick, depuis que j’ai un disque dur dans mon 1200.

Au passage j’ai ici heu… 6 disques dur actuellement en fonctionnement chez moi, ils vont tous bien

Sauf les IBM parcequ’un IBM fonctionne en moyenne 4 mois

[anonyme]

anonyme

#23523

RAFO:

J’avais le meme probleme mais uniquement sur ENV-ARCHIVE;

En fait, tu dois avoir une protection d’ecriture sur els fichiers de ton disque.

Essaye de l’enlever en mode SHELL.

protect ALL -REWD, ou un truc comme ça.