Exfat fájlrendszer olvasási furcsaságok

Debian GNU/Linux

Sziasztok!

Egy érdekes problémával küzdök épp. Adott egy Sony PXW-Z280 kamera, mely SxS kártyára rögzít exfat fájlrendszerre. Windows 10-re felcsatolva szépen működik és látható az összes mappa és fájl. Ugyanez MX Linux 21 (Xfce4) alatt már nem így van, mert nem látható az XDROOT-on belüli Clip mappa. Cd paranccsal azonban sikerül belépni a nem látszódó Clip mappába, de azon belül hiányzik az összes MXF fájl. A dmesg semmilyen hibaüzenetet nem ír a felcsatoláskor.
Ezután kipróbáltam azt, hogy a felcsatoláskor ne a kernel modul legyen használva, hanem mount.exfat-fuse -vel legyen mountolva. Ez esetben a kártya teljes tartalma tökéletesen látszódik és olvasható. Azonban ilyenkor meg az a gond, hogy a rendszer nem csatolja fel magától a kártyát.
Olyan megoldás érdekelne, hogy rendesen lehessen olvasni a kártya tartalmát és működjön az automatikus felcsatolás is. Az mindegy, hogy a natív kernel modult vagy a fuse-t használom.
A cél az lenne, hogy az operatőr kollégák ugyanúgy át tudják másolni a másolni a kártya tartalmát mint Windows alatt.

  • 729 megtekintés

( SySERR | 2022. 12. 13., k – 15:00 )

Még nem oldódott meg a probléma, ezért feltöltöttem egy image fájlt amin reprodukálható a probléma: http://syserr.hu/SxS.tar.gz
Kicsomagolás után a 16GB-os fájl mountolható.

Ha így van felcsatolva: mount -o loop -t exfat 16G_p1 /mnt
akkor az XDROOT mappában nem látható a Clip mappa, de cd paranccsal be lehet lépni és nem látszódnak az MXF fájlok sem.

Ha pedig így kerül mountolásra: mount -o loop -t exfat-fuse 16G_p1 /mnt
akkor az XDROOT mappában látható a Clip mappa ugyanúgy mint Windows alatt és láthatók az MXF fájlok is.

Nekem ment (csak http, "modern" böngészők meg nem szeretik).

Fedora37-n is reprodukálható, szerintem kernel fejlesztőket érdekelné a dolog. De hogy hol kell kernel bugot bejelenteni, azt nem tudom.

Amúgy az MXF-ek is simán olvashatók, ha tudod, hol vannak. Szóval valami a dir listázásánál van.

+1, meg tudja az ilyesmi oldschool dolog (rejtett fájl attributum) szopatni az embert.

2-3 éve próbáltunk ketten is másolni egy 16 v. 32 gigás USB pendrájvra egy 4-5 gigás windows ISO-t. Mindig arra panaszkodott h. nincs elég szabad hely a pendrajvon. Talán a másolás közepén, mert ha jól emlékszem elkezdte a műveletet. Pedig bőven volt szabad hely. Újraformáztuk, bőven nagy partició volt rajta, mégsem engedte még az üres particióra sem. Másnap megint előszedve a témát, csaptam a homlokomra, h. bazdmeg FAT32 van a pendrajvon, ott meg 2,1GB a max fájlméret. Ez meg egy 4-5 gigás ISO amit másolni akarunk rá.

Mondjuk a balfasz mikroszoft intézős hibaüzenet is megérne egy kurvaanyázást annak aki így találta ki.

Szerintem ez a MS részéről szándékos volt, hogy 4 giga fölé növelték a .wim fájlt, és nem darabolták. Gondolom elegük lett, hogy mindenki szépen könnyedén, Linux alatt is fénysebességgel írogatta a Win10-es telepítőket. Így meg úgy voltak vele, hogy eleve Windows kelljen hozzá, és az ő USB Media Creation Tool keresztnevű fostalicskájukkal tudjon csak mindenki telepítőt felírni. Persze tévedtek, mert fel tud a Rufus is, talán Belena Etcher is, meg Linuxon a WoeUSB, de azért régen kényelmesebb volt, hogy az ember a hivatalos oldalról a legfrissebb Windows .iso letöltése után csak kézzel csinált a kérdéses meghajtóra egy FAT32 partíciót, arra kézzel kimásolta az .iso-ból a telepítőfájlokat (tömörítők is ki tudják tömöríteni) és már működött is UEFI-s gépen bebootolva (hiszen a FAT32 partícióról azt hiszi az UEFI, hogy EFI partíció), nem kellett hozzá semmilyen extra szutykot letölteni, telepíteni. Túl könnyű lett volna, ha ez így marad. Persze, most is lehet kézileg .wim fájlt darabolgatni, de itt világosan kell látni, hogy ez nem szükséges lépés, csak a szopatás kedvéért van.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Jó, ez szép és jó, de ez a DISM megint valami windowsos megoldás a darabolásra. Itt most arról írtam, hogy pl. Linux alatt hogy lehet. Volt arra is leírás valami blogon, 7-zip-pel vagy mivel darabolva, de irtó bonyás, és nem is arról van szó, hogy lehetetlen megcsinálni, hanem hogy feleslegesen van bonyolítva.

Windows alatt eddig is 1001-féle eszköz volt rá. Ott eleve nem téma, mert a hivatalos MS-féle Tool is simán felírja, de a Rufus, Etcher, stb. is. Elvileg az Etcher megy Linux alatt is, de még nem próbáltam. A WoeUSB-t még régen, most nem tudom működik-e.

Szerk.: ez azt írja, hogy Linux alatt a wimtools csomagból a winlib-imagex split használatával lehet darabolni, állítólag a wimsplit is ezt használja. Persze megint egy plusz szoftver, amit lehet csak a MS miatt telepíteni. Ha akarnák, Redmondban simán meg tudnák csinálni, hogy 3,5 gigás darabokra szeletelve lennének eleve a .wim fájlok a telepítőmédián.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Nálam Arch-on nem látszik, ha exfat kerneldriverrel csatolom fel (6.1-es kernel), se a fájlkezelők nem látják, se az ls, fzf parancs, sem az automatikus kiegészítés. Ennek ellenére shellben bele lehet lépni a Clip mappába (cd Clip), és abban látszanak akkor XML és BIN fájlok, de nincsenek MXF fájlok. A user mode FUSE exfat-tal felcsatolva valóban látszanak, a Clip mappa és az MXF fájlok is. Az exfatfsck azt mondja, hogy a fájlrendszeren nincsenek hibák:

exfatfsck 1.3.0
Checking file system on /home/bla-bla/16G_p1.
File system version           1.0
Sector size                   2 KB
Cluster size                512 KB
Volume size                  15 GB
Used space                   98 MB
Available space              15 GB
Totally 11 directories and 13 files.
File system checking finished. No errors found.

Ennek ellenére én nem írnám ezt a kernel exFAT driver számlájára. Könnyen lehet, hogy a Sunyi kamera nem egészen szabványos exFAT fájlrendszert gyárt, amit a Windows, FUSE nagyvonalúbb implementációja megeszik probléma nélkül, de a szabványokhoz jobban ragaszkodó kernel driver meg nem megfelelően kezeli.

Aki le akarja tölteni a kolléga linkjéről a tömörített lemezképet, az wget-tel vagy curl-lel szedje. A modern böngészők valóban nem szeretik a titkosítatlan http:// miatt, de érdekes, hogy nem is a böngésző reklamál, hanem a szerver dobja vissza 403-as hibával a böngésző kérését.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Feltöltöttem: http://syserr.hu/SxS_teljes.tar.gz
A fájl kis mérete ne zavarjon, mert a teszt előtt nulláztam a kártyát és a rajta lévő valós tartalom tényeg csak ennyi. Kicsomagolás után meglesz a ~16GB.

Az fdisk ezeket a szektorméreket mutatja:
Disk /dev/sdf: 15,03 GiB, 16139681792 bytes, 7880704 sectors
Disk model: SBAC-US30       
Units: sectors of 1 * 2048 = 2048 bytes
Sector size (logical/physical): 2048 bytes / 2048 bytes
I/O size (minimum/optimal): 2048 bytes / 2048 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start     End Sectors Size Id Type
/dev/sdf1        4096 7880703 7876608  15G  7 HPFS/NTFS/exFAT

Tehát majd ennek megfelelően kell az imaget is felmountolni.

( zeller | 2022. 12. 13., k – 15:17 )

Szerkesztve: 2022. 12. 13., k – 15:17

legalább egy uname -r kimenetet tegyél már ide, hogy tudjuk, melyik kernelverzióval van gondod...

Ja, és az a probléma, ami több, mint fél év alatt nem oldja meg magát, nem érdemli meg, hogy foglalkozzunk vele :-)

( igiboy | 2022. 12. 13., k – 17:42 )

/etc/udev/rules.d/ környékén keresgélnék, hogy az adott kártya bedugásakor mit hajtson végre. Pl. egy scriptet kifejezetten csak ezen kártya bedugásakor.

( salaud v | 2022. 12. 13., k – 17:52 )

Mostanában telepített arch linux esetén jött nálam elő hasonló anomália, új rendszer, gondoltam már van a kernelben r/w ntfs és exfat driver, nem szívok a fuse-al, menjen natívan. Valami fél nap google keresés után sikerült "kitalálnom" hogy fstab-ba milyen opciókkal legyen csatolva micsoda, hogy menjen az r/w és minden látszon.

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. /  "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

A kernelben lévő Paragon-féle NTFS driverrel vigyázz, mert sok visszajelzés szerint bugos, adatvesztést, inkonzisztenciát okoz. Az exfat-tal viszont nem kéne gondnak lennie, az egy sok éve kész driver.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

UUID=3BAF980A69D7A64F			  /media/XXX	 ntfs	 auto,users,rw,uid=1000,gid=1000,dmask=027,fmask=137	0 0
UUID=XXXX-XXXX				  /media/XXX	 exfat	 defaults,uid=1000,gid=1000,umask=0002			0 0

Így működik minden rendben. Nincs probléma(eddig) az NTFS-el sem, de fél napom ráment mire ez elértem. A fuse driverrel kb semmi gond nem volt, csak kissé lassúcska volt. Mindegy, már marad így.

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt. / Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!! / Mindenki jó valamire. Ha másra nem, hát elrettentő példának. /  "Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993