OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů


Právě je 28.03.2024, 15:27

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 12 ] 
Autor Zpráva
PříspěvekNapsal: 09.05.2018, 14:19 
Offline
Pan Generální
Uživatelský avatar

Registrován: 18.05.2013, 14:56
Příspěvky: 2331
Has thanked: 303 times
Been thanked: 637 times
Aktuálně používám ESXDOS 0.86 beta 4, alespoň tak je označený balíček, ze kterého jsem to instaloval.

Občas se mi stane, že po nějakém ukládání dojde k rozbití obsahu adresáře. Nedokázal jsem vypozorovat při jaké přesně operaci. Mám pocit, že se to stalo párkrát při ukládání snapshotů, jindy při vytváření TAPek a zapisování do nich atd...

Chyba se přímo na ZX Spectru neprojeví. Projeví se až v okamžiku, když se pokouším s úložištěm pracovat na PC (v Linuxu, Windows pro tento účel nepoužívám). Soubory, které jsem na ZXS zapsal se zdají být v pořádku, jenže okolo nich jsou soubory nesmyslné, jakoby ostatní položky adresáře byly vyplněné náhodnými daty. Nesmyslné je úplně všechno, jméno souboru, velikost, datum atd...

Vím, že se mi to stávalo i s poslední ofic. verzí 0.85. Za tu dobu, už jsem si docela jistý, že to není závislé na ZX Spectru ani na tom, jestli používám Nobyho DivIDE 57c, nebo Velesoftovu lehce vylepšenou verzi 57d2. Nezávisí to ani na úložišti, děje se to jak s různými CF kartami, tak s SD/MMC v adaptéru (s HDD se mi to zatím nestalo, ale to může být náhoda), obojí různých velikostí (CFky mám nejčastěji 4G a 8G, SD karty od 32MB do cca 4G, poslední případ byl se 128MB).

Blbé je, že se to nestane vždy.

Občas udělám pár zápisů a vše se zdá 100% ok, karta projde i fsck. Jindy udělám pár snapshotů a musím kartu zformátovat (mkfs.vfat) a obnovit soubory ze zálohy. Oprava filesystému nikdy nepomohla, chaos je pro PC utility neřešitelný.

Nedaří se mi vypozorovat tu konkrétní situaci, kterou by bylo možné popsat a nahlásit jako chybu, nemluvě o tom, že se ESXDOS fórum zdá být přinejmenším skomírající s minimální aktivitou. Kdysi jsem tam něco psal a vše bez odpovědi.

Proto se nejprve ptám tady... vím, že je tu pár lidí, co se v ESXDOSu vyznají víc do hloubky.

Aktuálně mám v ZXS 32MB MMC kartu s minimem souborů. Pokud se mi na ní závada projeví, byl by to vhodný kandidát udělat binární image karty k podrobnějšímu zkoumání.

A nemyslím, že by to souviselo se spolehlivostí hardwaru. Občas se mi stane, že se ZXS z nějakého důvodu zhroutí a zblbne, ale párkrát se mi to stalo i v situacích, kdy se ZXS zdálo zcela stabilní.

Divné taky je, že se projevy chyby podezřele podobají.

Nějaký nápad, co s tím? Příp. čím bych mohl přispět k lokalizování chyby?

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS


Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 10.05.2018, 07:24 
Offline
Kecálek

Registrován: 05.08.2017, 07:38
Příspěvky: 95
Bydliště: Praha-Kladno-Kralupy
Has thanked: 5 times
Been thanked: 10 times
Mě zlobilo Nobyho DivIDE 57c nejprve v důsledku vadného kontaktu CF karty. Adresáře nezobrazovaly obsah a ten byl často vadný. Po opravě se DivIDE, zvláště po delším fungování, občas nepochopitelně zasekne, restart ZXS nepomůže (restart vypadá témeř normálně, ale zakousne se v černé obrazovce po které už nenásleduje "C 1982 Slinclair research Ltd..").
Pomůže až odpojení DivIDE, pak zas všechno funguje jak má třeba měsíc. Obsah karty zůstává v pořádku.

_________________
Harlequin 128, ZX Spectrum Plus, ZX Sparrow 48K, HP 200LX


Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 10.05.2018, 07:35 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 05.09.2013, 14:08
Příspěvky: 1067
Bydliště: Smolenice
Has thanked: 130 times
Been thanked: 473 times
Môžem potvrdiť Cygnusove skúsenosti. divIDE 57c mnou poskladané, ESXDOS 0.8.5 z domovskej stránky. Niekoľkokrát som našiel na CFkarte rozbitý filesystém. V ZX v pohode čitateľná, v PC sa javí ako bordel, nepomôže nič, len sformátovať. Neukladám takmer vôbec nič, takže som to pripisoval NMI menu, keďže ono jediné niečo na kartu ukladá, pretože pochybujem, že pri čítaní sa dá filesystém takto rozbiť. Tiež som sa to chystal nahlásiť (asi Duškymu, keďže NMI menu je od neho) a tiež som začal používať malú 16MB CF kartu, aby bol dump karty čo najmenší.

_________________
To err is human, but to really foul things up requires a computer.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 10.05.2018, 07:55 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 12.05.2013, 19:23
Příspěvky: 1910
Bydliště: Vsetín
Has thanked: 517 times
Been thanked: 812 times
Přiznám se, že jsem teď dost často dělal snapshoty na SD kartu v DivMMC Future, když jsem převáděl kazety do kopíráku. Nikdy se mi to nestalo. Asi vytáhnu DivIDE a vyzkouším to s CF kartou. Používám Esxdos 0.8.5. U DivIDE se při vstupu do NMI ukládá obrazovka do TMP adresáře. U DivMMC to nedělá, protože má větší paměť.

_________________
cs.speccy.cz, ondraspo186.8u.cz, zx-spectrum.cz


Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 10.05.2018, 10:32 
Offline
Pan Generální
Uživatelský avatar

Registrován: 18.05.2013, 14:56
Příspěvky: 2331
Has thanked: 303 times
Been thanked: 637 times
solaris104 píše:
U DivIDE se při vstupu do NMI ukládá obrazovka do TMP adresáře. U DivMMC to nedělá, protože má větší paměť.
Pravda, ale adresář TMP jsem zatím rozbitý neviděl. Vždy se to týkalo adresářů, se kterými jsem nějak pracoval.

K tomu mému poslednímu případu, myslím, že jsem snapshot neprovedl, pouze jsem vytvořil TAPku, párkrát provedl SAVE, zkopíroval TAPku, přejmenoval, vyrobil další adresář a zkopíroval do něj... taky jsem vytvářel a mazal TRD image. NMI menu jsem používal, ale k načítání odjinud, ne v tom rozbitém adresáři.

Měl jsem v úmyslu udělat video na YouTube, kde bych ukázal souhrn základů, co se s ESXDOSem dá dělat, protože se mne na to pár lidí ptalo a jednak jsem usoudil, že by bylo fajn to předvést prakticky a druhak se mi to nechce opakovat pro každého znovu.

Zkusím ten proces zopakovat a budu si víc dávat pozor na to, co dělám. Při troše štěstí zůstane i záznam postupu, jak se to přihodilo.

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS


Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 12.05.2018, 14:16 
Offline
Pan Generální
Uživatelský avatar

Registrován: 18.05.2013, 14:56
Příspěvky: 2331
Has thanked: 303 times
Been thanked: 637 times
Teď jsem zkusil toto (youtube je prostě jen jméno adresáře)

.mkdir youtube
.cd youtube
.to a.tap
SAVE "s" SCREEN$
Napsat pár řádků BASICu (PRINT, BEEP, nic extra)
SAVE "test"
.to -c
.dumpmem -s 16384 -l 6912 screen.bin

A je rozbitá (viz screenshot), udělal jsem image a zkouším ještě jednou opatrněji. Nejprve čistím kartu pomocí
dd if=/dev/zero of=/dev/sde, pak vytvářím nový oddíl typu c (začátek 2048, konec 62719, sektorů 60672) a vytvářím FS pomocí mkfs.vfat /dev/sde1.

Teď na MMC kartu kopíruji soubory znovu ze zálohy, je toho necelých 400kB a znovu zkouším v ZXS.

Nj. jenže podruhé se mi chybu vyvolat nepodařilo.

Zkusil jsem vyrobit TAPku, uložit dump, vyrobit adresáře a TAPku do něj, vyrobit TRD, otevřít různé TAPky pro zápis a čtení a do jedné zapsat, vyrobit dump, zatímco byla jiná TAPka otevřená... jednou v průběhu a jednou po tom všem jsem MMC kartu zkontroloval v PC, vše ok.
Kód:
cygnus mnt # fsck.vfat /dev/sde1
fsck.fat 3.0.28 (2015-05-16)
/dev/sde1: 71 files, 519/15129 clusters
Divné.

Fakt je, že poprvé jsem neměl kartu vynulovanou. Provedl jsem jen mkfs.vfat před naplněním soubory pro ESXDOS. Ale i to by byla chyba na straně ESXDOSu, kdyby se nechal zmást daty, která má ignorovat.

Ani když chyba nastala, ani potom, jsem nepoužil NMI.

Zvláštní taky je - viz screenshot - co se ve jménech souborů objevilo. V image MMC karty se ty řetězce dají najít na 3 místech, přičemž jedno z míst by mohl být ten adresář (opět screenshot) a další nejspíš zbytky po souboru před přepsáním filesystému. Zdá se, jakoby ESXDOS načetl sektor odněkud a plácnul do něj obsah aktuálního adresáře a to celé zapsal. To by nakonec i mohl být důvod, proč se to neprojeví s kartou, která má vynulované sektory, dokud není alespoň trochu zaplněná.


Přílohy:
2018-05-12_zx_esxdos_rozbita_fatka_02.png
2018-05-12_zx_esxdos_rozbita_fatka_02.png [ 20.08 KiB | Zobrazeno 6946 krát ]
2018-05-12_zx_esxdos_rozbita_fatka_01.png
2018-05-12_zx_esxdos_rozbita_fatka_01.png [ 12.93 KiB | Zobrazeno 6946 krát ]

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS
Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 12.05.2018, 16:15 
Offline
Kecálek

Registrován: 10.07.2014, 01:57
Příspěvky: 168
Has thanked: 25 times
Been thanked: 225 times
po precitani threadu som mal ideu, kde by mohol byt problem.


a to sice, ze vo FAT filesysteme sa pre adresare v ich direntry neuklada dlzka adresara, takze dlzka adresara je dana len dlzkou cluster chainu, ktory je vo FAT a teda je to nasobok velkosti clustra.

tu by mohol byt problem, ked by esxdos pri vytvoreni adresara neinicializoval cely jeho cluster ale by len ulozil dva zaznamy (pre '..' a '.') a este treti (s flagom 'free direntry'), ktorym by zoznam poloziek ukoncil.

a tak som spravil maly test - pripravil som image, ktory by inicialne nemal vsetky byte vynulovane ale povedzme nastavene na 'A'.

na vyrobu takeho image som spravil skript:
Kód:
#!/bin/bash

dd if=/dev/zero bs=16M count=1 | tr '\000' 'A' > test16M.raw
/sbin/mkfs.vfat test16M.raw

raw2hdf -v1.1 test16M.raw test16M.hdf
hdfmonkey put test16M.hdf esxdos086-BETA4.zip.dir/sys/ /
hdfmonkey put test16M.hdf esxdos086-BETA4.zip.dir/bin/ /
hdfmonkey mkdir test16M.hdf /tmp


nabootoval som emulator, a vytvoril v roote adresar YT (.mkdir yt). bol som zvedavy co sa stalo a tak som ani dalej nepokracoval a z modifikovaneho image som vytiahol particiu, aby som ju mohol namountovat v linuxe.
Kód:
dd if=test16M.hdf bs=534 skip=1 of=mod.raw


no a potom uz len:
Kód:
mkdir dir
mount -o loop mod.raw dir
ls -al dir/YT


a bolo to tam:
Kód:
total 51318642
drwxr-xr-x 2 root root       2048 Apr 23  1982 .
drwxr-xr-x 6 root root      16384 Jan  1  1970 ..
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA
-r-xr-xr-x 1 root root 1094795585 Oct  1  2012 AAAAAAAA.AAA


nedalo mi to, nejak sa mi nepozdaval pocet tych "fantomovych" zaznamov (48 - to nie je ani jeden cely cluster, ani zvysok clustra po zalozeni '.', '..' a jedneho prazdneho entry) a tak som pozrel do image okato, ze co tam vlastne je:
Kód:
0002c800  2e 20 20 20 20 20 20 20  20 20 20 10 10 10 00 00  |.          .....|
0002c810  97 04 00 00 00 00 00 00  97 04 42 00 00 00 00 00  |..........B.....|
0002c820  2e 2e 20 20 20 20 20 20  20 20 20 10 10 10 00 00  |..         .....|
0002c830  97 04 00 00 00 00 00 00  97 04 00 00 00 00 00 00  |................|
0002c840  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c850  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c860  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c870  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c880  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c890  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c8a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c8b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c8c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c8d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c8e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c8f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c900  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c910  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c920  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c930  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c940  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c950  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c960  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c970  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c980  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c990  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c9a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c9b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c9c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c9d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c9e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002c9f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0002ca00  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002ca10  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002ca20  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002ca30  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002ca40  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002ca50  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002ca60  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002ca70  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002ca80  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002ca90  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002caa0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002cab0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002cac0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002cad0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
0002cae0  41 41 41 41 41 41 41 41  41 41 41 41 41 41 41 41  |AAAAAAAAAAAAAAAA|
...


no a tu to uz dalo cele zmysel. esxdos sice inicializuje aj dalsie entries, ale len v prvom sektore celeho clustra, takze pri 2K clustri mi zostali 3 sektory neinicializovane a to je presne 3*16 = 48 suborov.

bolo by fajn taku kartu vyskusat vo windowse, lebo tusim som sa kedysi s Miguelom bavil presne o tomto ukoncovani a tusim vtedy vyplynulo ze windows pri prvom 'free' direntry ukonci prehladavanie adresara (linux zjavne nie)...

chybu zreportujem Miguelovi


Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 12.05.2018, 21:20 
Offline
Kecálek

Registrován: 10.07.2014, 01:57
Příspěvky: 168
Has thanked: 25 times
Been thanked: 225 times
este kvoli uplnosti, aby som vylucil teoriu o "pouziti dat z ineho miesta na disku", upravil som skript na pripravu testovacieho image:
Kód:
#!/bin/bash

for ((i=0;i<65536;i+=2))
do
   printf -v p "%04X" $i
   r=$p$p$p$p$p$p$p$p   #8
   r=$r$r$r$r$r$r$r$r   #64
   r=$r$r         #128
   echo -n $r
done > test16M.raw

/sbin/mkfs.vfat test16M.raw

raw2hdf -v1.1 test16M.raw test16M.hdf
hdfmonkey put test16M.hdf esxdos086-BETA4.zip.dir/sys/ /
hdfmonkey put test16M.hdf esxdos086-BETA4.zip.dir/bin/ /
hdfmonkey mkdir test16M.hdf /tmp


v skratke, do kazdeho sektoru som inicialne pripravil unikatny text v podobe 4ciferneho hexa cisla opakujuceho sa 128krat (512/4)

vysledok po teste:
Kód:
$ ls dir/YT | uniq -c
     16 02CA02CA.02c
     16 02CC02CC.02c
     16 02CE02CE.02c

tu pekne vidno ze su to 3 rozne sektory: 0x02ca, 0x02cc a 0x02ce a v kazdom z nich je 16 suborov.

no a este overenie v mod.raw:
Kód:
$ hexdump -Cv mod.raw | grep -E '\|02C[ACE]'
0002ca00  30 32 43 41 30 32 43 41  30 32 43 41 30 32 43 41  |02CA02CA02CA02CA|
[skratene]
0002cbf0  30 32 43 41 30 32 43 41  30 32 43 41 30 32 43 41  |02CA02CA02CA02CA|
0002cc00  30 32 43 43 30 32 43 43  30 32 43 43 30 32 43 43  |02CC02CC02CC02CC|
[skratene]
0002cdf0  30 32 43 43 30 32 43 43  30 32 43 43 30 32 43 43  |02CC02CC02CC02CC|
0002ce00  30 32 43 45 30 32 43 45  30 32 43 45 30 32 43 45  |02CE02CE02CE02CE|
[skratene]
0002cff0  30 32 43 45 30 32 43 45  30 32 43 45 30 32 43 45  |02CE02CE02CE02CE|
ukazuje, ze sa dane stringy nachadzaju len tam, kde povodne boli (podla adresy vo vypise hexdumpu).


Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 13.05.2018, 01:07 
Offline
Pan Generální
Uživatelský avatar

Registrován: 18.05.2013, 14:56
Příspěvky: 2331
Has thanked: 303 times
Been thanked: 637 times
ok, vzal jsem zazálohovaný image, který v Linuxu vypadá chybně, vrátil na MMC kartu a zkusil na WXP a W10.

Na WXP SP3 se opravdu zobrazí správný obsah, tj. jen ty dva soubory, které jsem do adresáře uložil (adresář YOUTUBE a soubory SCREEN.BIN a A.TAP - viz výše).

Nezapisoval jsem (alespoň ne vědomě), ověřil v Linuxu, že chyba stále trvá a zkusil na W10.

Stejně jako na WXP, i W10 64b verze 1709 se adresář zobrazí bez chyb.

Zkusil jsem na to ve W10 poštvat kontrolu scandiskem. Vyskočila hláška, že byly nalezeny chyby, nechal jsem opravit (žádné detaily jsem se nedozvěděl) a znovu zkontroloval v Linuxu a funguje to, W10 opravily chybu, kterou ESXDOS napáchal. I fsck.vfat po scandisku projde.

Jen tam nacpaly i adresář "/System Volume Information" - mor na ně... :P


Přílohy:
2018-05-12_zx_esxdos_rozbita_fatka_04.png
2018-05-12_zx_esxdos_rozbita_fatka_04.png [ 12.76 KiB | Zobrazeno 6860 krát ]

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS
Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 14.05.2018, 00:26 
Offline
Pan Generální
Uživatelský avatar

Registrován: 18.05.2013, 14:56
Příspěvky: 2331
Has thanked: 303 times
Been thanked: 637 times
misticjoe píše:
Chápu to správně tak, že když budu s kartou šaškovat pod windows, tak na danou chybu nenarazím?
Skoro...

Když budeš používat Windows, tak zůstane chyba víc skrytá a nebude tak moc vadit, ale scandisk ji odhalí a bude chtít opravit. Nezkoušel jsem, co to provede, když s chybným adresářem budu ve Windows pracovat, měnit ho, přidávat do něj soubory, možná to bude stále ok, možná ne...

V každém případě, jediné správné řešení je opravit ESXDOS.

A mimochodem - zkuste to někdo na DivMMC, mělo by se to chovat přesně stejně jako s DivIDE.

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS


Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 14.05.2018, 20:37 
Offline
Kecálek

Registrován: 10.07.2014, 01:57
Příspěvky: 168
Has thanked: 25 times
Been thanked: 225 times
zxcygnus píše:
A mimochodem - zkuste to někdo na DivMMC, mělo by se to chovat přesně stejně jako s DivIDE.
otestovane na divmmc vo fuse a na zxuno (divmmc pre zx nemam ;]), sprava sa rovnako, az na to, ze na karte pre zxuno mam 4K bloky, takze tych "fantomovych" suborov bolo o 64ks viac ;]


Nahoru
 Profil  
 
 Předmět příspěvku: Re: ESXDOS a občasné rozbití FATky
PříspěvekNapsal: 20.05.2018, 18:13 
Offline
Pan Generální
Uživatelský avatar

Registrován: 18.05.2013, 14:56
Příspěvky: 2331
Has thanked: 303 times
Been thanked: 637 times
Busy píše:
A bude to uz podporovat lubovolne vyrazy vsade tam kde treba nejaky parameter ?
Co jsem zkoušel, tak proměnné stále nelze používat, ani v CAT, ERASE, ani v příkazech za tečkou. Např. ERASE a$ ohlásí "No Such DRIVE, 0:1" i když v a$ je jméno existujícího souboru (ohlásí totéž i když proměnná není definovaná).

Trochu teď s verzí 0.8.6 experimentuji, chyba se špatnou inicializací položek v adresáři je rozhodně opravená, funguje to správně.

Přibyl příkaz .hexview a .rm (nevím kdy přesně, ale ve srovnání s 0.8.6 beta 4, možná už tam obojí bylo dlouho), příkazem rm se tedy stává i mazání souborů a adresářů víc konzistentní.

Příkaz .128 mi sice funguje, ale 128k BASIC se brzy po zadání něčeho resetuje, možná to je problém na který upozorňoval Velesoft, že se různé 128k BASICy liší? Nevím a netrápí mne to, protože jsem ho ani předtím téměř nepoužíval.

Konečně funguje .partinfo, ve staré beta4 nefungoval.

.dumpmem mi ukládá nuly, když jsem zkusil uložit -s 0 -l 16384, předtím ukládal obsah ROM DivIDE (stejně jako když zkusím SAVE "rom" CODE 0,16384 na TRDOSu, tak neuloží ZX ROM, ale TRDOS), na jinou oblast - RAM to asi funguje správně.

Jinak asi vše při starém. Co je nejdůležitější, chová se to stabilně a zatím jsem nerozbil žádnou FATku.

Myslím, že mnohem víc než LFN chybí nějaký pěkný filemanager.

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 12 ] 

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 6 návštevníků


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz