a nie lepiej 'minix' ? poprzednik ext2. Długie nazwy są.

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 ???

korekta. po stwierdzeniu zero odczytujemy z następnej pozycji (X+1) numer ostatniego sektora i potem dwa bajty określające pozycje końca pliku w tymże sektorze.

p.s draco zara odpowiem na Twój post. Chwilow musze zniknąć :(

hehe. mówisz byłby problem w trakcie dopisywanie do pliku? A ile razy dopisujesz do pliku wykonując funkcję APPEND (OPEN #x,9,0,"d:pathfilename.ext")? A ile razy odczytujesz ten plik?

W takim wypadku moje rozwiązanie wydaje się być mniejszym złem  :lol:

[ Dodano: Wto Gru 14, 2004 21:21 ]
można przenieść. oznaczenie KMK/S2I są tylko po to, aby ułatwić ich rozpoznawanie - ograniczające się do odczytu 1 sektora. Pozatym KMK jak na razie ma większe możliwości niż SIO2IDE - bardziej pojemne dyski, bezkonkurencyjną szybkość i sektory 512 bajtów, etc. Więc chyba logiczne jest, że nieda się skopiować x MB czy y GB o rozmiarze sektora 512 na (do) dysk (plik) ATR w SIO2IDE. Można owszem użyć HDD, lecz to zdaje się jest używane do pozostałych "wielkich dysków" - np. dyski z APE:

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)

tak wiem. Dlatego staram się pilnować. A to co sie da, odrazu wywalać.

[ Dodano: Nie Sty 09, 2005 12:12 ]
Po rozmowie z Draco doszedłem, do wniosku, iż zaimplantuje tylko linki symboliczne do systemu plików. Twardelinki zmusiłby do przeniesienia informacji o długości pliku/dacie utworzemnia i atrybutach i dodanie liczby dowiązań (ile wpisów na dysku używa tej m apysektorów i danych przypisanych do tej mapy) , do mapy sektorów. Byłoby to co prawda bardzo dobre, jeśli chcielibyśmy odzyskiewać danel, lecz jak na razie biorąc pod uwagę to, że spowoduje to bardzo duży spadek szybkości dla operwcji na katalogach - trzeba odczytać wpis w katalohu, potem przejść do mapy sektorów wpisu odczytać pozostałe informacjeo wpisie i wrócić do katalogu, odczytać następny wpis. itd. Przeniesienie tychże informacji do mapy sektorów jest konieczne ze względu na np. taką sytuację:

mam plik D1:ala.txt. hadrlinkiem do tego pliku jest np. D1:tekstyolga.txt.

chcę wykonać edytuj na hardlinku (olga.txt) - zmieniłem sobie zawartość pliku - zmieniła się jego długość, data modyfikacji, atrybuty -  wypadałoby też uaktualnić oryginalny wpis. Teraz trzeba by przeszukać strukturę katalogów lub dodawać w mapie sektórów link do każdego wpisu w każdym katalogu, co z koleii utrudni funkcję przenoszenia plików , sotrowania katalogów, etc... więc to jest poproastu zbyt skomplikowane

Myślę, że do kopiowania takie znaczniki w bootsektorach nie są potrzebne. Do stwierdzenia, czy jeden dysk da się skopiować na inny, wystarczy porównanie fizycznej geometrii zwracanej przez PERCOM.

Co do bootsektora, proponuję przyjąć taką zasadę: jeśli rozmiar sektora dysku (wykazany w PERCOM) jest >= 512, to i bootsektor ma tę wielkość; a w przeciwnym wypadku ma 128 bajtów.

Znacznik w bootsektorze przydałby się natomiast do zaznaczenia, czy dysk jest wymienny (dyskietka) czy nie (partycja). W przypadku twardego dysku oszczędziłoby to DOS-owi konieczności każdorazowego sprawdzania, czy "dyskietka" została od ostatniego razu wymieniona, czy nie ...

Nie wiem, wydawało mi się jakoś, że chcesz obsługiwać też bootsektory po 256 bajtów.

A co z dyskiem *wymiennym* podpiętym przez interfejs KMK? Czymś takim jak kiedyś Syquest: napęd z wyjmowanym wkładem. Typ interfejsu, i to czy obsługuje sektory 512-bajtów itd., nie ma tu nic do rzeczy.

Co do rozmiaru linku: najlepiej byłoby mieć możliwość dobrania linku optymalnego do wielkości dysku, ale to już zależy od tego, kto będzie implementował filesystem, bo to komplikuje procedury obsługi plików. No i wydaje mi się, że link ośmiobitowy to jednak overkill, ...

Khm, to mają tylko dyski IDE, a co z SCSI?

Chodzi mi generalnie o to, że może lepiej jest po prostu dać "sprzętowo niezależną" flagę w bootsektorze, która mówi, czy dysk jest wymienny, czy nie. Zamiast bawić się w identa na IDE, brak identa na flopie, i w jeszcze coś innego na SCSI ...

Czyli jak wolisz 8)

Znaczy przesada. W najlepszym razie zyskasz na tym tyle miejsca w ramdysku, co stracisz na kod obsługi tego.

Komendę INQUIRY może i mają, ale one niewątpliwie zwraca dane w innym formacie, niż IDENTIFY DRIVE, nieprawdaż? A znowu flop wcale niczego takiego nie ma.

Musiałbyś więc wewnątrz kodu filesystemu kombinować, z jakim *konkretnie* urządzeniem masz do czynienia. A po co? Przecież filesystem potrzebuje tylko wiedzieć, jakie dysk ma cechy (fizyczne: ilość sektorów, wielkość jednego sektora, removable/fixed, nic ponadto chyba), a nie, czy to SCSI czy nie. FS ma być, krótko mówiąc, sprzętowo niezależny.

Co więcej, w ogóle cały DOS nie potrzebuje wiedzieć, czy to SCSI czy nie - nie ma sensu komplikować DOS-u włączaniem do niego wariantów kodu, które obsługiwałyby poszczególne typy urządzeń, skoro można tego łatwo uniknąć, zwalając całą robotę tego typu na program formatujący partycję. Niech on sie martwi, jak rozpoznać, czy dysk jest removable czy nie - a DOS niech polega tylko na jego ustawieniach.

Nic. Czyli to, co do tej pory się robi - zakładać, że to jest dysk wymienny...

SpartaDOS to jeszcze się da rozszerzyć (np. bajt 43 bootsektora: $00 - fixed, $FF removable), AtariDOS i MyDOS-a olać, nic się nie da zrobić.

Oj, to prawda. Obsługa filesystemu, który ma mieć sektor o rozmiarze powyżej 256 bajtów, przy ośmiobitowych rejestrach indeksowych jest trochę bolesna. Pewnie dlatego zawsze się na Atari trzymano tych 256-bajtów ...