Freda Trej (Drej, niewiem, jak to sie pisze  :rolleyes: - mniejsza z tym), bo Zweii już był - wersja exportowa nosiła numer 2 - miała dodaną muzyczkę i była zingliszowana  :lol:  Pozatym, milewidziana byłaby kontynuacja Lasermanii  :lol:  :lol:  Lub Robbo w jakiejś zupełnie nowej postaci.  :lol:  Albo Misja 3 - np. scenerię zrobić w tropikach, jak niedawna superprodukcja na grzybku  :?:  :!:  :idea: Hmmm. Adaptacja DynaBlaster (tm)  :lol:  (róólo gierka) się przyjęła, a jakby zrobić adaptację SuperFroga z platformy A(le )miga lub James Pond. Całkiem extra gierki ???

u mnie odśwież nieskutkuje :/

No to Serious jest pod znakiem zapytania.... Stryjek: co ty na to? I gdzie Voy'a wsiąkło ?!? Miał siem odezwać.

Dałem plamę z czytaniem syzygy  :oops: na usprawiedliwienie powiem tylko , że jestem na numerze w którym niema użytego GHE...

Aż zaraz obaczę, co Vasco zdziałał od czasu, gdy pofatygował siem do mnie z Jurgim, celem przerobienia gotowej  :?:  :!:  :?:  źródłówki do czytnika plików GHE coby chciał działać w pamięci zwykłej - niechciała wyjść z pamięci RAM pod ROM'em (mojego byłego ulubionego obszaru na umieszczanie kodu :D ). hehe sam miałem problemy, by ją z tamtą wyciągnąć, a dziwiłem się biednemu Vascowi... Ale wylazła  :D

Lizard: fajne koło wymyśliłeś  :lol:

:mrgreen:

róólo!

A jednak prog taki istnieje! :D Dajcie go Draco, niech zrobi wersję ATARI! i umieści zamiast Selftestu w DracOS!!!! Zdaje się już była propozycja (przy OS'ie dla '816), aby takie coś zrobić !!! :D A tu prosze gotowy programik. Ruskie przeliczniki ??? Ciekawe jakie wartości tam zastosowano... :D

nie. nieupieram się przy nich. pierwotynie służyć miały posłużyć np. przy operacji kopiowania - jeśli kopiujemy z jednej dyskietki na drugą, to system prosi o podanie żródłowej / docelowej dyskietki. natomiast przy kopiowaniu z partycji na ta samą partycje taki komunikat co najmniej by denerwował - tak samo jak jego brak przy różnych dyskietkach.  Dla użądzenia CAR np. jest specjalny BOOT, umożliwiający start z niego. Sektory odczytu wstępnego są w odpowiednim miejscu.

Pozatym fakt. w FAT jest podobny znacznik. Jednak niezapożyczyłem go z tego systemu. - jak pisałem u góry FAT to największa z istniejących pomyłek - systemy plików.

nom  :lol:  :lol:  :lol:

hehe. a jak link jest 32-bitowy, to co odczyt jednej pozycji z tabeli trzeba wykonać

lda ....
ora ...
ora ...
ora ...
beq = koniec pliku?!?

bezsensu. policz ile cykli stracisz na każdy odczytany sektor. a przy partycjach KMK do szybkości transferu liczy się każdy cykl zegara, gdyż, to dysk czeka za Atarką, a nie na odwrót !!!!!!  8)

popieram tą ideeeeęęęę :D Bardzoooo by sieeee przydałoooo :D

[ Dodano: Czw Gru 09, 2004 21:21 ]
niby loguje automatycznie, lecz IE zapomina i to dość często (jak dla mnie) lofin i password. :/

yyy... a co to takiego :?

to jest tylko propozycja FS. więc niechaj będzie 1970, chyba, że jeszcze ktoś ma coś nt temat do powiedzenia.

z tego co tutaj napisano, wnioskuję iż "link symboliczny" jest czyś w stylu Windowsowego "*.lnk" :?

hmmm...  raczej nie problem. bo w statusie są wolne bity.

pytanie bylko, czy scieżkę docelową zapisać tylko w postaci np. "D3:utilsedittextpantherpanther.com"m czy też dodać (przed samą ścieżką) bezpośredni link do 1 sektora mapy sektorów tego pliku - coby nieprzeszukiwać całej gałęzi podkatalogów w celu odnalezienia danych. :?

niestety niebyłoby to lepsze. Czemu? Logika się kłania. W Twojej propozycji przy odczytaniu pozycji X z tabeli, należało by też za każdym razem czytać również następną, celem sprawdzenia, czy nie jest to aby ostatni link w tabeli, a potem cofnąć ofset do poprzedniej pozycji. Chyba, żę byłby t ostatni link, to wtedy pobieramy ilość bajtów danych znajdujących się w ostatnim sektorze danych.

W tym co ja zaproponowałem wystarczy se czytać pozycję X i dopierom gdy ona jest równa 0, to wiemy że to jest koniec pliku i odczytujemy ile bajtów jest zajętych w ostatnim sektorze.

Ileż prostrza jest procedura w/g co ja zaproponowałem, że o czasie jej wykonywanie niewspomnę.

2 lub 3 odpadają, gdyż FS potrzebuje tylko jednego sektora (jeśli 512 bajtów/sektor - IDE KMK róólo) - FS wykożystuje cały rozmiar sektorów 1-3 - 256 lub 512 bajtów na sektor. Można użyć numeru 1. w ostateczności gdyby się ktoś upierał. Z resztą przy tak dużych partycjach czy ktoś kłóciłby się o 1 sektor? Niewydaje mi się.

ok. Powstaje jeszcze jedno pytanie. Czy jeśli plik jest wpisem symbolicznym, to czy bit plik też ma być aktywny (bo jest to w końcu plik, który coś zawiera - ścieżkę dostępu do innego pliku) i taki link symboliczny jest przez system tak traktowany - ma swoją mapę sektorów, czy też link stymboliczny, to poprostu ma on przypisany 1 sektor, w którym jest tylko ścieżka dostępu do właściwego pliku z ew. numerem 1szego sektora dla mapy tego pliku? Ja ripsotuję, aby była mapa, gdyż np. jeśli ktoś przykładowo zagnieźci właściwy plik gdzieś głęboko, to rozmiar 1go sektora może niewystarczyć. tymbardziej, jeśli byłyby używane ew. długie nazwy plików i katalogów.

yyy.... o ile symboliczny link zrozumiałem (tak mi sie wydaje), to tzw, twardego linku w opisany przez ciebie sposób nie bardzom, powiedziałbym wręcz w cale. Proszę troszkę jaśniej jakby co.

nfs = ntfs ?!? bo jakoś nie kumam :(

prosiłbym troszkę jaśniej co to jest ten słynny "inode" :?

yyy.... amiga mówicie. :? czy ten hardlink, to coś takiego podobnego do struktury dysku na OFS/FFS Amigi, że wpisy w katalogu zajmują 512 bajtów i jestw nim wszystko o pliku/podkatalogu łącznie z mapą sektorów :? Dobrze rozumiem :? Każdy z takich sektorów jest ze sobą powiązany, a nie zdefragmentowany dysk tak spowalniał wyświetlanie katalogu (o przepraszam szuflady ;) ), a jak do tego ikony dochodziły, to j?ż w ogóle :/ jeśli tak, to nasuwają mi sie dwie myśli:

przeniesienie wpisów z katalogu do mapy sektorów ma bardzo dużą zalete - tfu tfu.... (tylko) zakładając padłby FS, to odzyskiwanie danych z takiej mapy było by bardzo proste, gdyż nazwe pliku, i jego atrybuty łatwo by przywrócić. Natomiast jeśli directory byłby w przedstawiony w przeze mnie sposób, to dane dałoby sie odzyskać, lecz jeśli uszkodzony zostałby katalog, to mamy tylko rozmiar pliku i jego zawartość, a o lokalizacji (położenia w konkretnej ścieżce dostępu) i nazwie pliku mowy niema. Z drugiej jendak strony patrząc, jeśli uszkodzimy sobie taki hardlink, który jest jako 1szy w katalogu, to praktycznie przepada reszta zawartości tego katalogu, bo nic już nie jest z nią powiązane :( Wydaje mi się prezentowana przeze mnie struktura katalogu za bezpieczniejszą pod tym względem. Coż nie ma rózy bez kolców ...

tu ostro musze zaprotestować!

FAT(12/16/32)? Ja określam tylko jako najbardziej tragiczny filesystem jaki wymyślono - mianowicie bardzo mi sie niepodoba samo sedno sprawy - czyli tablica FAT - jeśli jakikolwiek jej fragment zopstanie uszkodzonuy, to dane lub ich część, którym przypożądkowane były numery Klastrów  :twisted:  (sektorów) w uszkodzonym obszarzem to NIE MA SPOSOBNOŚCI 100% ODZYSKU DANYCH z czegoś takiego. Dlatego mapy sektorów są o niebo lepsze pod tym względem od systemów FAT. Pisząc i obmyślając FS HiDOS'a, starałem się uniknąc tego co zawsze mnie denerwowało w trakcie zawodowego odzyskiwania danych z tych systemów. Każdy nawet najbardziej skomplikowany program, który ratuje dane z padniętego FATa opiera się na tym, żę dysk przed crashem był zdefragmentowany i zapisuje sektory po koleji. A ile użyszkodników na świecie defragmentuje dysk co godzinę? 1/100000 :? Bo w/g to +/-99.9999% ludzi jeśli robi to raz choćby na tydzień to góra. Więc zalożenie takich programów można sie w ucho ugryżć i nic z tego.  Jeśli dodatkowo uszkodzony został też katalog, w którym znajdował się plik, który chcemy odzyskać, to już żaden program nie jest w stanie stwierdzi dokładnej (POPRAWNEJ) długości pliku. dlatego właśnie programy tego typu stosują sztuczki tego typu, że rozpoznają (przynajmniej próbóją)( rozpoznać co to za plik/podkatalog próbójemy odzyskać i w/g dokumentacji do danego pliku próbóją określić właściwą długość pliku. Z reguły 97% takiej operacji kończy się niepowodzeniem. Natomiast opisany schemat mapy sektorów, który jest w FS HiDos'a, w 100% stwierdzi dokładną długość pliku. A jeśli już mapa sektorów zostanie uszkodzona, to 1, 10 może 50 plików, a nie wszystkich naraz! więc moje zdanie jest bardzo krytyczne pod adresem systemów rodem z REDMOND! (I kropka!)  :lol:

A długie nazwy: ja proponuję, aby długość wpisu zrobić np. 64 bajty, z czego 32-40 bajtów przeznaczyć na nazwę pliku. A znaki narodowe można zapisać przecież w standardzie UniCode, w tego nazwa miała by od 16-20 znaków. I standard UniCode zachowany i zero problemu... Co wy na to ? Czy może zostawić konwencję 8 + 3 ???

kto wie kto wie.... proszę się uważnie przyjrzeć. Może kogoś rozpoznamy na tym zdjęciu  :lol:  :lol:  :lol:

co fakt to fakt.

Dracon: a czy podcza wczytywania Vasco PD Library #10 (muzyczki CMC i MPT, Vasco + Pentagram) działało poprawnie z Tygrysem? Jeśli tak, to dam mu swoją procke Trackmo.

a żeby je tam zmieścić trza by użyć co najmniej MPEG4  8O  :lol: