mc: vfs: extfs: msdos, vfat

Segédprogramok

Sziasztok!
Van ugye az 

mc

(amit szeretunk), es annak van egy olyan nagyon jo funkcioja, hogy tamogat egy csomo virtualis filerendszert. Pl. bele lehet ma'szni egy "iso" file-ba, tar-ba, archivokba (*.a), stb. Ezek joresze ugy van implementalva, hogy a /prefix/share/mc/extfs konyvtarban az egyes "filerendszerekhez" tartozik egy-egy program (gyakorlatban sh-szkript vagy perl-szkript), ami par cmdline-argumentumon keresztul atveszi az mc-tol az "igenyeket", igy pl. az iso-nal a listazast az 

isoinfo

paranccsal csinalja, es annak a kimenete'bol" (awk segitsegevel) general egy olyan kimenetet, amit az 

ls

is adna. Stb-stb.
Kerdes az, hogy tud-e valaki az isoinfo-hoz hasonlo, de DOS-os filerendszereken (msdos=fat12, fat16 es/vagy vfat=fat32) valo listazast/infot/filekinyere'st leheto"ve tevo" programrol? Netalanta'n ma'r direkt mc-re szabott szkriptje van valakinek erre a problemara? :) Van nehany regi szep idokbol (386, 486) szarmazo mente's, dos-os particiok 1:1-be, partiz/parszaz mega's file-ok, oszt kenyelmesebb (lenne) igy turka'szni bennuk, mint su, mount, loopback, su kile'p, turka'l, turka'l, su, umount ...
Ha nagyon nem letezik effele dump-program, lehetne irni is egyet, a fat12/16 nem is veszes, de a vfat-os kreten unicode16-os fileneveket remalom lenne felprogramozni, ahhoz nincs sok affinitasom (az egeszhez sem, de talan a fat12/16-ot me'g meg is csinalnam, ha nagyon nincs erre ke'sz program... deb alatt van a `dosfstools`, de az csak mkfs es fsck-t tartalmaz).
A.

  • 1888 megtekintés

( apal v | 2007. 01. 14., v – 13:44 )

Hm, senki nem hallott ilyesmirol?

mindegy, nemsokara keszenlesz ;]

aztan publikald is... ;) 

fatinfo-0.1.tar.gz

van me'g egy csomo hianyossaga (timestamp, docum, utf16 kulturalt kibontasa, forras kommentezese, modularizalas, par opcio, autoconf/automake), de kezdetnek talan nem rossz.

Lehet turka'lni mc-ben is a regi szep ido"k archivumaiban ;) es az jo ;)

A.

Hat, ahhoz hogy ebbol kulturalt csomag legyen, me'g sokat kene vele dolgozni... legalabbis autoconf/automake, librecode, illetve az osszes potencialis buffertulcsordulast meg egyeb izeket at kene nezni. Majd szolok ha megvannak ;]

Esetleg ha valaki meg tudja mondani, hogy autoconf/automake szinten hogyan lehet megcsinalni, hogy a cflags az alapbol ne -O2 -g hanem valami mas (-Wall -pedantic -ansi -O3 -D_GNU_SOURCE) legyen, az jo lenne. Illetve me'g azt is akar, hogy csakugy siman forditson, es ne ilyen *.Tpo vagy milyen fileokon izeljen... de ez mar az en bajom.

A.

Nem tom mennyire gond, én már félig belőttem rá az autoconf/automake párost, szépen megy a configure is meg minden. Nem használ .Tpo fájlokat. Azt asszem a libtool miatt csinálja.
Gentoo alatt úgyis az a CFLAGS lesz amit a rendszer használ. A configure.ac-ba lehet az AC_CFLAGS dologgal jáccani... -O paramétert nem érdemes beégetni, mert sokan csak -O2 forgatnak. A többi akár jó is lehet. Játszak vele, vagy elég, ha a publikus verzióhoz képest küldök egy patch-et (NEM nyúltam a forrásba, de szvsz a patch a legegyszerűbb ilyen esetekre)?

Nem tom mennyire gond

;] El tudnad kuldeni? A patch-et is aka'r vagy komplette.

-O paramétert nem érdemes beégetni, mert sokan csak -O2 forgatnak

A cflags-okat azert szoktam igy megadni, mert igy a legnagyobb a kompatibilitasa a tobbi ka've'vo"zo"vel ami hordozhatosag szempontjabol nem utolso szempont. Ez foleg az -Wall -pedantic -ansi. Az -O3-at meg azert szeretem mert az bekapcsolja me'g a -finline-functions optimalizalast is, ami elegge sok hibaleheto"seget kiderit (pl jobban erzekeli a valtozok inicializalas nelkuli felhasznalasat, kretenebb esetekben is kuldi a warningot, stb). A -D_GNU_SOURCE meg azert maradhat, szerintem, mert a gyakorlatban ugyis gcc-vel fordit az ember, kavefozokon is.

A.

Szerintem akkor a -finline-functions optimalizálást kézzel kell kérni. Optimalizálási szintet nem erőszakolunk, mert a forrásalapú disztribek peccselik ki elsőnek. Meg nem is illik. Ha én -Os szinten szeretnék optimalizálni, akkor tessen kedves lenni meghagyni nekem ezt az örömöt :durc: :).
a -D_GNU_SOURCE -ba meg az éfvilágon senki bele nem kötött.

A patch este elküldésre kerül, de megoldom a CFLAGS nyűgöt.

mert a forrásalapú disztribek peccselik ki elsőnek
Hm, ezt nem tudtam. Erdekes. Miert? Azt gondolna' az ember, hogy hamar binarist csinalnak, akkor az legyen jo' gyors. Egyebkent meg tenyleg toklenyegtelen, mert ezeket azert teszem bele, hogy tenyleg minden hulyeseget kiszu'rjon a fordito. Najo persze optimalizalas se art, de ilyen tipusu problemaknal nem ez a szu"k keresztmetszet.

Igen. Csakhogy a forrásalapú disztribek pont azért születtek, hogy az optimalizálás általánosabb részét a felhasználóra bízzák. Ugyanis vannak olyan rendszerek, amik adott optimalizációs flagek mellett hipergyorsak, nélkülük meg mint a csiga. Nem azt mondom, hogy no optimalization, mert az baromság lenne részemről. Mindössze azt jelzem, hogy erőssen meg kell fontolni, hogy mire van a projektnek _valóban_ szüksége. a -finline-function például tipikusan mehet a projekt kívánalmai közé, a -D_GNU_SOURCE ismét. De a -O optimalizációk annyira rendszerfüggők, hogy azt én semmiképpen sem merném a projektből szabályozni.

Egyebkent meg tenyleg toklenyegtelen, mert ezeket azert teszem bele, hogy tenyleg minden hulyeseget kiszu'rjon a fordito.

Ezt nem kétlem, ám azt igen, hogy ez a széles felhasználótábor nagyfokú érdeklődésére tartana számot. Egszerűbben mondom: ha valaki fordít, nem érdekli mi megy ki a képernyőre. Akkor érdekli őt baromira, ha a kiíromány error-ral kezdődik. Tehát ezek a dolgok főleg neked fontosak. a configure esetén lehet élni azzal a trükkel, hogy a CFLAGS-ot kiexportálod környezeti változóba és csá. Ehhet fogja majd a configure.ac beli flageket szúrni.

Amúgy a -finline-function megnehezíti asszem a gdb dolgát...

Most akkor mi is ez az *.im[gz] dolog? Oke, WinImage, de ehhez a programohz nem volt me'g szerencse'm (es nem is valoszinu, hogy lesz a kozeljovoben...). Ez is maga az image, csak tomoritve valahogy (zip, gz, bz2)? Vagy a nyers image-n kivul ez tartalmaz ma's meta-informaciot?

A.

Hm, lehet hogy inkabb file + magic-ok hasznalata kene. Egyreszt kulturaltabb, masresz en *.filerendszer-nek nevezem el az image-ket (*.fat12, *.fat16, *.xfs, *.ext3, ..., ahogy jo"n). Igy legalabb rogton lehet tudni hogy milyen a filerendszer...

No mindegy, ez ma'r inkabb hitke'rde's, nem fontos ;)

( egmont | 2007. 01. 15., h – 21:49 )

> unicode16-os fileneveket remalom lenne felprogramozni
Ja, ez elvi síkon egyáltalán nem nehéz, de valóban nyűgös babra munka. Szerintem nézd meg az ntfs-3g kódját, valszeg onnan le tudod nyúlni.

en a librecode-ra gondoltam, az elvileg tud utf16-ot kodolni. meg ugyis majd meg kell irni hogy barmely kodlapra kikodolja (pl utf8-ra), mert most ez az utf16 also 8 bitje't nezzuk dolog gyk a latin1-gyel egyenerteku. a magyar e'kezetes filenevek sze'pen atjonnek, leszamitva az o"-t meg az u"-t.

A.

> en a librecode-ra gondoltam

A librecode őskövület, nem fejlesztik, bugos, és tök nem standard, simán lehet hogy csomó embernek nincs telepítve. Viszont az iconv*() és az mb*() függvénycsalád teljesen szabványos libc függvények, mindenütt jelen vannak, és jól is működnek.

> a magyar e'kezetes filenevek sze'pen atjonnek, leszamitva az o"-t meg az u"-t.

Feltéve, hogy egyrészt latin2 a Linuxod karakterkészlete, ami napról napra kevesebb Linux rendszerre teljesül, másrészt hogy nincs olyan karakter a fájlnévben, amelyiknek ezen byte-ja véletlenül éppen '\0', '/' vagy valami hasonló extrém dolog volna.

( arpi_esp v | 2007. 01. 22., h – 06:04 )

van az mc-ben valami floppy kezelo extfs, ha jol emlexem a: -knet lehetett ra hivatkozni, es az mountol.as nelkul irta/olvasta a fat-es lemezeket... esetleg abbol kiindulni?

A'rpi