Instalacja dla FreeBSD:

1) cd /usr/ports/sysutils/fusefs-kmod

2) su

3) make && make install

4) kldload /usr/local/modules/fuse.ko

5) ctrl/d

a dalej jak powyżej, mkdir atari8fs itd.

PS. czekamy na moduł obsługujący FS Sparty :)

@Amun-Ra: Zbadam temat. Póki co na własną rękę można użyć checkinstall i podać odpowiednie dane.
@drac030: Dzięki za procedurę instalacji. FS dla Sparty w planach :)

Czy znalazłby się ktoś, kto przetłumaczyłby na języki obce (w tym en) README i *.man (będą w następnej wersji)?

Plan jest taki, żeby atari8fs składało się z:
- modułu kernela obsługującego tablicę partycji APT i udostępniającego w systemie partycje Atari z CF/SD/MMC/HDD,
- filesystemów ataridosfs i spartadosfs obsługujących konkretne FSy Atari,
- filesystemów atrfs, dcmfs, xfdfs, profs (zacząłem od najpopularniejszego) montujących obrazy dysków dostępnych w plikach o wymienionych formatach w takiej postaci, jak będzie ją udostępniał kernel obsługujący APT.
Tak więc atrfs służy tylko do udostępnienia obrazu dyskietki zapisanej w formacie .ATR, jako ciągłego pliku (może nie powinien to być FS - liczę na jakieś sugestie) i udostępnia w strukturze stat informację o parametrach "nośnika". Sam ataridosfs (a w przyszłości również spartadosfs) ma korzystać z gołego ciągłego pliku. Najlepiej gdyby działało to tak, jak montuje się obrazy .img (loop), ale póki co nie wiem jak to działa i muszę się naumieć.
Te FSy można by zaimplementować jako moduły kernela, ale wybrałem FUSE bo gdyby ktoś w przyszłości napisał jego implementację dla windowsa (+ obsługę APT), to mogłoby to działać też i tam.

Edit: Może się okazać, że FUSE nie było dobrym pomysłem dlatego kod jest napisany w C, żeby można było łatwiej go wsadzić do modułu kernela.

Edit 2: Potem można by też zdefiniować reguły dla udeva do automatycznego montowania zasobów z Atari z nośników wymiennych - wtedy user nie musiałby już kompletnie nic robić z linii poleceń.

Co to APT i ciągły plik?

Zgłaszałem już swoje uwagi autorowi, ale skoro program jest dostępny publicznie, to niech i uwagi będą.
To powinna być biblioteka w Ć, żeby było łatwo dołączać ją do innych programów w różnych językach. Montowanie z FUSE lub kernelem to bardzo szczególny przypadek, tak samo zły, jak graficzny interfejs usera w MakeATR czy pluginie do TC. Obsługa obrazów i filesystemów ma już bazylion implementacji, w każdej inne błędy i ograniczenia. Tymczasem mogłaby siedzieć w bibliotece, zakodowana raz a dobrze, i nie byłoby problemu ze zrobieniem z tego narzędzia obsługiwanego z wiersza poleceń, z interfejsem graficznym, jako elementu emulatora komputera lub stacji dysków, wtyczek do obsługi archiwów, systemów plików, etc., omg., wtf.
Jeśli chciałbyś to zrobić w ten sposób, to chętnie pomogę w kodowaniu i/lub testowaniu.

Czemu akurat miałoby nie działać we FreeBSD? Jak jest mono, to translator zadziała. Od tego momentu masz kod w C/Javie/(lub innym języku), a z tym chyba nawet we FreeBSD sobie umiesz poradzić, nie? ;)

Po ponad 6 latach możnaby z tym ruszyć ;) Ja jestem starej szkoły i proponuję zacząć od analizy i projektu w wiki (np. Trac jak w przypadku FAIL), zamiast szybko coś naklepać a potem refaktoryzować.

ten konkretny temat to nie calkiem to o co mi chodzilo ale moze przerodzi sie w cos na czym mi zalezy ... wiec tak niesmialo dodam, ze aby uszczesliwic usera to oprocz operacji na plikach jednak zapis i odczyt sektora tez byl.

xxl: To akurat jest najławiej zrobić.
drac030: No jasne, tylko trzeba jeszcze zamontować przed i odmontować po - jak pokazał mono, sześć dodatkowych poleceń do wykonania. Czasem możesz użyć skryptu, czasem nie. Czasem masz system, dla którego FUSE nie istnieje, np. Windows.
IMHO to niepotrzebne komplikowanie, skoro wystarczy otworzyć plik i wyciągnąć z niego lub zmienić w nim trochę bajtów. Jednym z "front-end"-ów takiej biblioteki może być również program używający FUSE, więc nic nie tracisz.

Primo, nie sześć, jeno trzy: 2 x mount, 1 x umount.

Secundo: zgodzę się, że "2x mount" jest kłopotliwe i należałoby je uprościć przez redukcję do 1 polecenia. Można do tego ułożyć skrypt, który będzie konkretnie montował obrazy dyskietek, bez ruszania reszty funkcji. Bo docelowo, gdy chodzi o rzeczywisty dysk, pierwszy mount odpada.

Ale ja szczerze mówiąc w ogóle nie rozumiem tych obiekcji, przecież postępowanie z tymi obrazami pod Fuse jest (prawie) dokładnie takie samo, jak z flopami, CD-ROM-ami i cokolwiek się pod Unixem montuje. Czy to taka różnica, montować z /dev a montować z innego katalogu?

No wybacz, ale co to jest za argument ;) Niech Microsoft zrobi.

A moim zdaniem to jest właśnie uproszczenie. Oddzielny program (typu franny) będzie po prostu bardziej upierdliwy w użyciu (jak bardzo, można łatwo sprawdzić używając zdalnie scp :P ). No i tu faktycznie masz 'n' nowych poleceń więcej, bo wszystkie czynności na systemie plików (ls, cp, rm, mv, chmod, i co tam się komu jeszcze zamarzy) musisz robić specjalnymi poleceniami, wpisując pewno jakieś opcje w linii komend. A jak zechcesz użyć mc albo interfejsu graficznego, to ... wget http://napisz.se. Faktycznie, uproszczenie jak diabli.

Dalej nie widzę _konieczności_ przekształcania tego na bibliotekę.

Choć oczywiście, dla zabawy, czemu nie, ostatecznie wszystko tu robimy dla zabawy (przyjemnej i pożytecznej ;) ).

A nie wątpię. Tylko wątpię w sens wkładania dodatkowej pracy celem przekształcenia tego w taką bibliotekę.

Poza tym, znając życie, projekt utknie w połowie i nie będziemy mieli ani jednego ani drugiego. Więc optowałbym za tym, żeby autor sobie dalej spokojnie pracował wg własnej koncepcji, a jeśli znajdzie współpracownika w osobie np. epiego, który przekształci to wszystko w bibliotekę, to też dobrze, byle to nie blokowało postępów pierwszego z frontów.

Domyślam się, że chodzi ci o ten "inicjalizer". Otóż wkopiowanie takowego - tak jak to już napisał epi - jest przy obecnym rozwiązaniu nawet bardziej możliwe niż przez ową "bibliotekę"; bo tam trzeba byłoby do tego napisać program, a tu wystarczy skrypt.

Przeczytaj własny post (nr 19), to się może dowiesz.

atrfs udostępnia plik ATR jako urządzenie blokowe ( FYPI: http://pl.wikipedia.org/wiki/Urz%C4%85dzenie_blokowe ), po to jest. Więc sektory tegoż są zapisywalne tak samo jak wszystkie inne sektory urządzeń blokowych.

Skoro po nic, to problem solved. W przeciwnym wypadku wydaje mi się, że albo pomyliłeś wątki, albo nie bardzo wiesz, o czym piszesz.

> Skoro po nic, to problem solved. W przeciwnym wypadku wydaje mi się, że albo pomyliłeś wątki, albo nie bardzo wiesz, o czym piszesz.

ten konkretny po nic ale jak wczesniej pisalem moze projekt przerodzi sie w cos co bedzie i mi uzyteczne :-)

mozliwe ze autor podejmie korzystna decyzje. trzy osoby maja uwagi a jedna jest zadowolona... ja bym sie zainteresowal 75% userow ;-)