1

Temat: propozycja FileSystemu (HiDOS F.S. v1.3)

Witam, ponieważ jestem chwilowo bez kompa - naprawia siem  :lol:  :lol:  :lol: Bozia niech temu magikowi w dzieciach wynagrodzi  :lol:  to postanowiłem zapodać opisy filesystemu, który jest już poprawiony po dość osterej krytyce Lizarda - sporo uwag i sugestii zostało uwzględnionych. Efektem czego trzeba rozpocząć kodowanie FS od nowa - próba przerobienia FS v1.1 zakończyła siem nie powodzeniem, więc stwierdziłem, że prościej będzie zrobić go od nowa :-) Zapraszam do lektury i wyrażenia swojej opinii oraz jakichś propozycji, bo trzeci raz od nowa tego mi sie chyba niebędzie chciało piosać.

FAQ: Cegła waży kilogram i pół cegły. Ile ważą dwie cegły ? :D

JIL 4EVER!

2

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

A będzie zakładanie haseł na foldery? przepraszam, podkatalogi? :F

3

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

A ma być?

Jeśli tak, to słucham propozycji.

Mi się wydaje, że niema to sensu, gdyż przed kim chciałbyś chronić podkatalogi. Każdy z osób, które są obecnie na scenie potrafiłoby złamać to co ewentualnie by się wymyśliło. bezwzględu na to co jest i co wykonało by się jakieś operacje typu AND, OR, XOR czyteż ROL czy ROR w zależności od chasła. trzeba by przecież gdzieś zapisać coś w stylu jakiejś sumy lub czegoś podobnego, a następnie trzeba by jakoś sprawdzić czy hasło jest poprawne. Chyba, że poprostu wyświetlać wszystko, to co wyjdzie z wykinku podania nieprawidłowego hasła, etc... W/g mnie niema to sensu. DO takich rzeczy wystarczy edytor sektorów (w HiDOS'ie jest prosty edytorek odwołujący się do procedur SIO z 32-bitowym numerem sektora, co pozwala na edytowanie wszystkiego - nawet RAMCart'a, czy RAMDysku jak zwykłego flopa bezwzględu na rozmiar sektora (128, 256, 512)...

:idea:  Chyba, że masz na myśli swoją rodzinke ...  :twisted:   :rolleyes: Ja u siebie mam hasełko na kompie - OS-ROM za to odpowiada i bez poprawnego siem do systemu nie wlezie - tam siedzi suma crc hasełka i z niego jest to sprawdzane... większość ustawień - np. kolory ekranu, marginesy, ust. klawiatury, etc. mam w pamięci CMOS układu Philips'a PCF8583 (zegarek RTC z pamięcią CMOS o pojemności 256 bajtów) i po każdym resecie ustawia siem wsio tak jak ma być, bez jakiś specialnych driverów czy nakładek na system.

FAQ: Cegła waży kilogram i pół cegły. Ile ważą dwie cegły ? :D

JIL 4EVER!

4

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Hasła - po co? Dobrego kodera nic nie za3ma, a resztę (osób) załatwi na amen  :twisted:

B5 (Hidden) - wpis jest ukryty

Przy funkcji "directory" i/lub przy próbie otwarcia wpisu wystąpi błąd (170/174 - file/directory no fonud) Dostęp do niego należy potwierdzić poprzez ustawienie odpowiednich bitów w komendzie OPEN podsystemu CIO.

... i tyle. Czy wiecie ile osób na Windzie nie wiem o tym  :D

Opis FileSystemu jest dlugasny, reszte quotes pozniej  8O

5

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

też tak uważam.
a opis długi, bo dokładny

FAQ: Cegła waży kilogram i pół cegły. Ile ważą dwie cegły ? :D

JIL 4EVER!

6

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Na Falconie pod MiNT-em mamy coś takiego, że nie katalog, ale całą patrycję można zaszyfrować i nikt tego nie złamie, bo używa się do tego algorytmów regularnej kryptografii. Ale szybkość takiego dysku jest pożal się ...

Inna metoda zahasłowania "katalogu" to multijuzerność taka jak pod Unixem: flagi katalogu ustawiasz na rwx------ i nikt kto nie zna twojego hasła się do tegoż katalogu nie dostanie (za wyjątkiem ruta, rzecz jasna).

Casper, specyfki ściągnąłem, ale na razie tylko przejrzałem z grubsza, bo siedzę chwilowo nad czymś innym, patrz:

http://atariarea.histeria.pl/forum/view … 8866#28866

Uwagi, wzajemnie.

KMK
? HEX$(6670358)

7

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

moze dlugie nazwy plikow?

http://atari.pl/hsc/ad.php?i=1.

8

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Ej, z tymi hasłami to żartowałem!
A o długich nazwach to mam wrażenie, że dyskusja już była?

9

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

nooo...

topic "Ograniczenia kontrolera HDD"

link do drugiej strony - tam gdzie pojawiły się długie nazwy

http://atariarea.histeria.pl/forum/view … p;start=30

[ Dodano: Pon Lis 29, 2004 1:01 ]
Hmmm.... strasznie tu cicho. czyżby żadnych zastrzeżeń do proponowanego filesystemu  8)  :lol:

FAQ: Cegła waży kilogram i pół cegły. Ile ważą dwie cegły ? :D

JIL 4EVER!

10

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Ja nie kumam poco wymyślać coś nowego? Raiser3 i wszystko ;)

What can be asserted without proof can be dismissed without proof.

11

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Może jestem ślepy, ale nie widzę w statusach plików oznaczenia, że "plik jest linkiem symbolicznym".

Poza tym dlaczego data ma być liczona od roku 1900? Czy ty piszesz to w roku 1900? Ja bym raczej napisał, że do wartości daty nalezy dodać np. 2000. To przedłuża żywotność filesystemu o 100 lat  :lol:

[ Dodano: 29.11.2004 11:45:58 ]
PS. Albo przynajmniej 1970, starsze pliki chyba na świecie nie istnieją, bo Unix liczy czas od 1 stycznia 1970 roku ...

KMK
? HEX$(6670358)

12

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

W mapie sektorów koniec danych oznacza sie jako:

jeśli jako numer sektora będzie $00 ($0000, $000000, $00000000 - zależne od długości linku), to następny link zawiera numer ostatniego sektora należącego do pliku/podkatalogu, następne DWA BAJTY zawierają numer 1-go wolnego bajtu w tym sektorze. W ten oto sposób jest oznaczany koniec pliku

czyli mamy wpisy:
- link przedostatni
- $00, $0000, $000000, $00000000 - zależne od długości linku
- link ostatni
- DWA BAJTY zawierają numer 1-go wolnego bajtu w tym sektorze.

"numer 1-go wolnego bajtu w tym sektorze" czyli w ostatnim sektorze z danymi - ile zostało zajętych tam bajtów :?: 

A nie lepisej  :idea: zrobić tak:
- link ostatni
- $00, $0000, $000000, $00000000 - zależne od długości linku
- DWA BAJTY zawierają numer 1-go wolnego bajtu w ostatnim sektorze.


Ponadto:  :rolleyes:

jeśli jako numer sektora będzie $FF ($FFFF, $FFFFFF, $FFFFFFFF - zależne od długości linku), to oznacza to, że (z reguły) plik nieposiada dla danego obszaru przydzielonego sektora na dysku (tak jak w SpartaDOS'ie, tylko tam było zero za numer sektora) i dane odczytywane z tego obszaru będą zawierać "same zera" - w taki sposób można "wyjeżdżać" poza rozmiar pliku - w trybie R/W (jednoczesny odczyt i zapis).

Co oznacza, że tego ostatniego sektora nie mozna używać- jest w mapie VTOC oznaczony jako zajety :?:

Czy nie lepiej uzyc wartosci 1 lub 2 lub 3 zamiast $FF, przeciez sektorow 1-3 i tak niewykorzystamy na dane inne niz boot  :!:

ORAZ:
Czy w mapie sektorów moze byc link wskazujacy adres do katalogu z ktorego pochodzi  8O . To ułatwi odzyskiwanie danych  :idea:

[ Dodano: Pon Lis 29, 2004 19:19 ]
Czy dobrze rozumiem:

drac030
Może jestem ślepy, ale nie widzę w statusach plików oznaczenia, że "plik jest linkiem symbolicznym".

Czyli chodzi o zwykly komentarz zamiast wpisu do katalogu. Na wzor AtariDos - $42,00,00,00,00,rem

13

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Czyli chodzi o zwykly komentarz zamiast wpisu do katalogu. Na wzor AtariDos - $42,00,00,00,00,rem

Ee, nie wiem czy się dobrze rozumiemy. "Link symboliczny" to jest (fizycznie) plik zawierający ścieżkę dostępu do właściwych danych. Każde "open" wykonane na tym "pliku" udostępnia dane wskazywane przez link.

Czyli np. mamy program D2:>DOS>DPA.COM. Jeśli z jakichś względów chcemy go uruchamiać jako WZGBLA.COM, to zmieniamy nazwę. Ale jeśli chcemy mieć możliwośc uruchamiania tego pod jedną nazwą i drugą, to trzeba zrobić kopię, co marnuje miejsce na dysku.

Marnowaniu zapobiega link symboliczny, który zajmuje tyle miejsca, co ścieżka dostępu do właściwych danych, a nie tyle, co same dane.

Konkretnie link symboliczny powinien zawierać zwykłą ścieżkę dostępu, czyli plik WZGBLA.COM, jeśli ma być linkiem do D2:>DOS>DPA.COM, ma zawierać tekst "D2:>DOS>DPA.COM", a jego wpis w katalogu ma mieć ustawiony atrybut, który będzie stanowił wiadomość dla DOS-u, że to jest link a nie plik, i nie otwiera sie bezpośrednio, tylko wczytuje ścieżkę zawartą w nim i otwiera dopiero to co ona wskazuje ...

KMK
? HEX$(6670358)

14

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

pod unix-ami masz 2 typy linkow:
-symboliczny
plik o atrybucie linku symbolicznego ma w swojej tresci sciezke dostepu do wlasciwego pliku/katalogu na ktorym powinny odbywac sie operacje

-twardy
tak naprawde to kazdy plik pod unixem jest linkiem (przypisaniem nazwy) do powiedzmy listy sektorow

ciekawsze som linki twarde: pod unixami mamy takom o to w uproszczeniu chierarchie od miejsca w katalogu do wlasciwych danych: wpis w katalogu (nazwa) -> inode (w uproszczeniu: lista sektoroof, +oznaczenie ilosci hardlinkoof) -> wlasciwe dane
kasowanie nazwy pliku oznacza skasowanie danych (czy oznaczenie wykozystywanych przez nie sektorow) dopiero gdy zadna inna nazwa nie odwoluje sie do zawartosci pliku (kasujac nazwy zmniejszamy licznik w inode) czyli gdy licznik hardlinkoof spadnie do zera

przyznam ze b.milo bym widzial to pod (k)atarynkom...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

15

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Ty się Jellonek naucz pisać  :twisted:

Po drugie zaś, linki symboliczne są lepsze - bardziej uniwersalne - niż hardlinki, bo hardlink może być tylko w obrębie tego samego filesystemu, softlink natomiast może wskazywać nawet na plik umieszczony fizycznie na drugim końcu świata (a to przez NFS, na przykład).

[ Dodano: 29.11.2004 21:13:03 ]
Korekta, zaćmienie, przepraszam  :?

KMK
? HEX$(6670358)

16

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

nfs pod malym atari :)
buahahahaha
mysle ze hardlinki bylo by b.prosto dodac do jakiegokolwiek file systemu

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

17

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Po drugie zaś, linki symboliczne są lepsze - bardziej uniwersalne - niż hardlinki, bo hardlink może być tylko w obrębie tego samego filesystemu, softlink natomiast może wskazywać nawet na plik umieszczony fizycznie na drugim końcu świata (a to przez NFS, na przykład).

Zgadza sie, oczywiscie, ale zauwaz ze symlink kosztuje ekstra inode'a, a hardlink nie. A inode (w przypadku atari to moglby byc adres sektora?) jest juz zasobem ktorego lekkomyslnie nie mozna marnowac bo ich liczba jest scisle okreslona i stala. (w zaleznosci od wielkosci filesystemu)

Takie 3 grosze moje, NA RAZIE nie staje po zadnej ze stron.

ps. jellonek, przylaczam sie do prosby konrada, - pisz mniej gg-owo ;)

18

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

ok. choc ciezko mi sie bedzie przestawic

co do inoda, to mysle ze dodac jedno pole do mapy sektorow nie bylo by problemem?

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

19

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

nfs pod malym atari :) buahahahaha

Na razie buhahaha. Na Atari ST swego czasu to też było buhahaha, a teraz po prostu jest.

Jeśli NFS nie przemawia ci do wyobraźni, to może przemówi ci, że softlink na dysku D3: może wskazywać plik na dysku D2:, hardlink natomiast nie.

Dlatego moim skromnym zdaniem softlinki są bardziej pożądane w filesystemie niż hardlinki. Jak używam Unixa parę lat, nigdy jeszcze nie miałem potrzeby utworzenia hardlinka, może jestem dziwny.

[ Dodano: 30.11.2004 01:09:31 ]

Zgadza sie, oczywiscie, ale zauwaz ze symlink kosztuje ekstra inode'a, a hardlink nie

Zauważam; jak napisałem, softlink to jest po prostu plik, który zamiast danych zawiera ścieżkę dostępu do właściwego pliku z danymi. Hardlink natomiast jest to wpis w directory odwołujący się do określonego obszaru danych. W takim układzie, jak ktoś już tu napisał, każdy wpis w directory jest hardlinkiem, tyle że niektóre filesystemy pozwalają by większa ich ilość niż 1 odnosiła się do tych samych danych.

Wciąż mimo wszystko uważam, że softlink jest lepszy. Mimo że jest wolniejszy i zajmuje inoda.

[ Dodano: 30.11.2004 01:12:11 ]

ok. choc ciezko mi sie bedzie przestawic

Nie bierz tego do siebie, ale to małpowanie angielskiej pisowni, kiedy mamy własną i to lepszą, jest deczko irytujące.

co do inoda, to mysle ze dodac jedno pole do mapy sektorow nie bylo by problemem?

Chyba nie ma potrzeby, wystarczy jeden bit w polu statusu.

KMK
? HEX$(6670358)

20

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

hm, rozwiazanie samo sie narzuca: zrobic zarowno symlinki jak i hardlinki :)

ps. swego czasu dyskutowalem (via mail) z Theodore Tso (tworca ext2fs oraz wlascicielem legendarnego dla niektorych komputera tsx11.mit.edu)
O ile dobrze pamiętam miał podobne zdanie do mojego (a raczej ja swoje zbudowalem na jego argumentacji oraz autorytecie ;)) ze jesli nie ma KONIECZNOSCI uzywania symlinkow, NALEZY uzywac hardlinkow.

21

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Zapewne dlatego, że hardlinki są szybsze i (jak słusznie zauważyłeś) nie zużywają inoda. Co do zasady się zgadzam.

Ale softlink ma - nawet w obrębie jednego filesystemu - pewną zaletę: jest łatwo odróżnialny od hardlinka.

Reasumując, hardlinki są "słuszniejsze", softlinki natomiast wydają się "bardziej użyteczne".

KMK
? HEX$(6670358)

22

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

Reasumując, hardlinki są "słuszniejsze", softlinki natomiast wydają się "bardziej użyteczne".

Lepiej bym tego nie ujal :D

23

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

pole to mialo by przechowywac liczbe dowiazan nazw do plikow, wiec chyba nie trafiles.
gdyby to mial byc link symboliczny to rzeczywiscie wystarczyl by do oznaczenia tego jeden bit, w wypadku (jakos milej przezemnie widzianego) hardlinku niestety oprocz informacji o tym iz jest to link potrzeba jeszcze ciut informacji...

mysle ze zarowno zaimplementowanie hard jak i soft linkow bedzie w hidos-ie poprostu czyms milym, prostym i przyjemnym  8)

nieco poza tematem:
a co do malpowania :)  to milo mnie rozbawilo jakobym mial z anglackiego zapozyczac to co jeszcze 1,5 wieku temu (no moze nieco dawniej) bylo stosowane w naszych rodzimych stronach.
lepsza pisownie? a co takiego lepszego w stosowaniu znakow z poza alfabetu rzymskiego?

predzej widze zapozyczenie z innych jezykow w pseldonimach co poniektorych zacnych uzyszkodnikow tegoz forum 8)

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

24

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

W przypadku hardlinka liczba dowiązań jest w rzeczy samej potrzebna, ale nie wiem, czy skuteczna implementacja tego byłaby naprawdę tak lekka, łatwa i przyjemna. Niewątpliwie wiązałoby się to z przeniesieniem informacji o pliku z directory do samego pliku (czyli do mapy sektorów zapewne), a to stawiałoby pod znakiem zapytania w miarę szybkie wyświetlenie katalogu ... zdaje się, że Amiga tak ma i pierwotnie na A500 to była spora porażka, nie pakujmy się w to.

Nieco poza tematem: nic mi nie wiadomo o tym, jakoby 1,5 wieku temu w Polsce pisano tak jak ty to próbujesz robić na forum. O ile mi wiadomo, polska pisownia wywodzi się zasadniczo z XVI wieku, więc z nieco wcześniejszych czasów niż sprzed 1,5 wieku. Co do okresu przed XVI wiekiem, to jestem świeżo po przekładzie dokumentu z początku wieku XV zawierającego - prócz zasadniczej treści - polskie roty przysiąg sądowych, więc proszę uprzejmie nie opowiadać mi banialuk, zgoda?  :rolleyes:

KMK
? HEX$(6670358)

25

Odp: propozycja FileSystemu (HiDOS F.S. v1.3)

spokojnie, spokojnie :)
nie bij :)
chodzilo mi tylko o to ze rowniez w polsce dla zapisu tego co teraz nazywa sie o kreskowanym uzywano podojonego o.
a co do moich zapiskow to fakt. na 100% sa mniej czytelne, przez co i moge sie poswiecic :)

[ Dodano: Wto Lis 30, 2004 1:01 ]
aaa, zapomnialem dodac...
zgoda  :lol:

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep