@xxl: Faktycznie w chwili obecnej zapisanie inicjalizera na dysku jest dość problematyczne. Można to zrobić wykorzystując obraz udostępniony atrfsem w krokach:
1. stat - sprawdzić rozmiar sektora i ich ilość
2. jeśli 256 to pierwsze 3 sektory mają 128b, wpp mają rozmiar jak inne sektory (chyba, że dysk był montowany z -f, wtedy trzeba liczyć)
3. 3 pierwsze sektory zapisać za pomocą dd if=inicjalizer of=image bs=128 count=3
W sytuacji gdy inicjalizer zajmuje więcej miejsca zaczyna się problem, bo trzeba modyfikować vtoc samodzielnie itp. - masa zachodu.
Faktycznie zapis sektorów jest w kodzie trzeba by tylko wystawić go np. jakimś ioctlem (to samo z odczytem sektorów) i napisać mały programik do tego, bo w systemie nie ma możliwości oidp (dd zapisuje bloki danych, ale nie zamarkuje już sektora we VTOC a to by taki programik robił).
Jeśli chodzi o zapis własnego katalogu - jeśli znasz filesystem, to nikt Ci nie zabroni pisać po obrazie (tym udostępnianym przez atrfs) ile dusza zapragnie, ale to można sobie w zasadzie robić nawet na samym ATRze - atrfs daje tu tylko to, że nie musisz analizować nagłówka (potrzebne informacje są dostępne przez stat), no i w następnej wersji będzie automatycznie przy każdym zapisie liczyło crc (jeśli jest użyty).
@epi,fox: Oczywiście nie mam żadnych obiekcji co do stworzenia porządnej biblioteki do manipulacji obrazami i fsami. Ztcw to epi ma już coś porządnie zaczętego - można by to pociągnąć dalej i potem wykorzystać w moich programikach. Też jestem zdania, że należy zacząć od Traca i analizy. Akurat ten fs jest moją przymiarką do FUSE (inaczej do końca życia nie wiedziałbym jak to działa i czy da się w tym coś napisać, jak szybko i czy i jakie są z tym problemy ;]).
Jeśli idzie o "6 instrukcji" to zauważcie, że 2 mounty są potrzebne tylko podczas montowania obrazu który jest w atr. Analoogicznie się ma sprawa z montowaniem dowolnego czegoś co mamy w pliku .img (używa się tylko /dev/loop do tego), ale ilość instrukcji pozostaje niezmienna. Jeśli będziemy mieć support do APT w kernelu i odpowiednie reguły w udev, to podłączając hdd przez usb, lub wkładając cf do kompa montowanie odbywać się będzie jak w przypadku cdromu - automatycznie i bez ingerencji użytkownika.
Faktycznie jest tak, jak mówi Drac030 - cel, jak mi przyświeca to zrobienie mechanizmu systemowego tak, żeby nie pisać kolejnego narzędzia, które w pewnej chwili rozbroi mnie sowimi ograniczeniami. Ponieważ mamy zwykłe obrazy i zwykłe fsy, to robimy systemowy support dla obrazów i fsów. I to wystarczy, a do kopiowania, przeglądania, czy innego psucia niech ktoś sobie używa co tam lubi.
W planach jest narzędzie pomocnicze, które powie jaki (i czy w ogóle) FS jest na zamontowanym (przez atrfs, lub na partycji) obrazie. Oraz drugie, które zależnie od rozpoznanego fsa zamontuje co trzeba jednym poleceniem. Nawiasem mówiąc mount jest dość elastyczny:
$ mount -t fuse#ataridosfs,fuse#spartadosfs image mountpoint
co spowoduje próbę zamontowania najpierw ataridosfsa a jeśli się to nie uda to spartadosfs. Trzeba by sprawdzić czy mój fs jest pod tym kątem przygotowany, ale na pewno nie jest to jakiś problem w implementacji.
Nie jest to całkiem tak, że sam fs wystarczy, potrzebne są dodatkowe narzędzia:
- mkfs.* do tworzenia filesystemu (czyli odpowiednik funkcji FORMAT dla konkretnego DOSa, a mkatr dla atrfs),
- fsck.* do testowania integralności i czynności naprawczych (taki odpowiednik CLX, VTOCFIX i pewnie jeszcze kilku narzędzi).
Ale nie od razu Kraków zbudowano.
A na koniec powiem, że zapominacie że nie ja pierwszy napisałem coś działającego. Jest plugin Pajero na windowsa, a ja ciągle używam FRANNY autorstwa Bobera, które bardzo mi się przydaje (wielkie dzięki). Poza tym support dla ATR i FSów jest w AspeQt, jest też w SIO2BSD. Może zamiast pisać od nowa coś swojego warto byłoby się lepiej przyjrzeć już istniejącym projektom i zrobić coś na ich bazie/pomóc w rozwoju?
hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje
