Hosszú vita a hosszú fájlnevekről

Kernel

Amikor a Microsoft elindította perét a TomTom ellen, megnevezett két olyan szabadalmat is, amely a FAT fájlrendszerrel kapcsolatos. Ez természetesen azt eredményezte, hogy ismét felerősödtek azok a hangok, amelyek azt mondták, hogy 1) ezeket a szabadalmakat érvényteleníttetni kell, 2) el kéne most már felejteni a FAT-ot végleg. Voltak azonban olyanok, akik egy harmadik utat javasoltak:

Keressünk egy megoldást, amellyel el tudjuk kerülni a szabadalmakban leírtak megsértését úgy, hogy közben megőrizünk a FAT fájlrendszer funkcionalitásának lehető legnagyobb részét. El is készült egy patch, amely bevezeti a kernelben a "CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES" opciót. Mint azt azonban a patch beküldését követő hosszas vitából láthatjuk, a workaround-ok nem minden esetben jelentenek egyszerű megoldást a problémákra. Még akkor sem, ha a azok nyomán az ügyvédek esetleg elégedettek is lennének az eredménnyel.

A patch-et az IBM alkalmazásában álló Andrew Tridgell - a Samba névre hallgató CIFS/SMB protokoll reimplementáció megalkotója - készítette, de nem ő, hanem a szintén IBM-es Dave Kleikamp küldte be az LKML-re.

Mit is csinál a patch?

Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option

When this option is enabled the VFAT filesystem will refuse to create new files with long names. Accessing existing files with long names will continue to work.

Azaz, ha az opció engedélyezve van, a VFAT fájlrendszer visszautasítja a hosszú (a tradicionális DOS-os 8.3-nál hosszabb) fájlnevekkel rendelkező fájlok és könyvtárak létrehozására irányuló kéréseket. Azonban nem akadályozza a már meglevő, hosszú fájlnevekkel rendelkező fájlokhoz való hozzáférést.

A patch mellé adott changelog nem ad semmi magyarázatot arra, hogy a készítője miért is akarja ezeket a változtatásokat elfogadtatni a fejlesztői közösséggel. Magából a szövegből a következőre lehet következtetni: a FAT szabadalmak a hosszú fájlnevek létrehozásáról szólnak, de nem tesznek említést egyáltalán a hosszú fájlnevekkel rendelkező fájlok olvasásáról. Szóval kétségtelenül az a gondolat járhatott a patch létrehozójának fejében, hogy ha a FAT szabadalom érintheti a Linux kernel jelenlegi VFAT implementációját, akkor biztos hogy nem érintené abban az esetben, ha a kernelben levő kód nem lenne képes létrehozni hosszú fájlnévvel rendelkező fájlokat a VFAT fájlrendszeren.

Elsőre ez egy ésszerű hack-nek látszik. Az interoperabilitás megmaradna a meglevő VFAT fájlrendszerekkel (azaz tudnánk olvasni azokat, még akkor is ha hosszú fájlnevű fájlok is lennének rajta), azonban a fenti kernelopció érvényre juttatása mellett nem tudnánk létrehozni VFAT fájlrendszeren hosszú fájlnévvel rendelkező fájlokat. Ezzel sokkal kisebb lenne az esélye annak, hogy a Linux megsérti a Microsoft szabadalmát.

De vajon, akkor miért volt kedvezőnek éppen nem mondható a patch fogadatása a kernelfejlesztői közösségben?

Egyrészt feltétlenül szerepet játszhatott a hűvös fogadatásban a szoftverszabadalmi rendszerrel szemben általánosnak mondható ellenséges hozzáállás és az, hogy nem nagyon van hajlandóság a közösségben arra, hogy kapituláljon e szabadalmi rendszer előtt. Ehhez adjuk még hozzá a FAT fájlrendszerrel - és annak tulajdonosával - szembeni lenézést és mindjárt világossá válik, hogy miért nem meglepő, hogy egyes fejlesztők nem érezték "szórakoztató" elfoglaltságnak a probléma megoldását.

A nagyobb probléma azonban az volt, hogy maga a patch nem írta le, hogy miért is kellene a régóta ugyanazon az elven működő kódot most egy csapásra "lebutítani".

A hosszú szál itt kezdődik. Az LWN - egyelőre csak előfizetőknek elérhető - cikke a témában itt olvasható.

( Csigaa | 2009. 05. 07., cs – 13:20 )

Ennek nincs is értelme: nem lesz read-only, csak írásra gyakorlatilag alkalmatlan.
Akkor már vagy az egész írást tiltsák le, vagy hagyják a fenébe úgy ahogy van...

Ez az opció bekapcsolható. Nem kötelező. Olyan cégek számára készült, mint a TomTom. Ha ilyen bekapcsolt opciójú kernelt szállítana egy cég a termékeiben, nem lehetne belekötni. Ez az elképzelés. A PNA-k ritkán akarnak hosszú fájlneveket írni. Ha írnak, akkor csak saját használatra írnak fájlokat (pl. GPS tracking log) és ezek a fájlok teljesen el vannak rejtve a használók elől, tök mindegy milyen fájlnevük van.

--
trey @ gépház

Az nem fogja csípni a szemét a microsoftnak, hogy attól függetlenül a kód még benne van a kernelben ami lehetőve teszi pl. a hosszú filenevek írását?

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Ezek már olyan finomságok, amin az ügyvédek évekig el tudnak vitatkozni. Valószínű, hogy a megoldás beküldése előtt egy talicska IBM ügyvéddel megvitatták a dolgot és ők ezt elfogadhatónak tartották. Legalábbis én biztos, hogy így tettem volna a helyükben.

--
trey @ gépház

Ebben mondjuk igazad lehet, hogy először az ügyvédekkel zsírozhattak a fejlesztők. Mindenesetre én úgy érzem, hogy valamennyire ez egy támadási felületet is adhat mások számára, egyfajta elismerése annak, hogy igen ebben igaza van a microsoft-nak. Bár lehet én látom hülyén a dolgokat.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Azt, hogy a Microsoft-nak igaza van-e vagy sem, azt nem az dönti el, hogy a kernelfejlesztők mit csinálnak, hanem az, hogy az illetékes eljáró bíróság mit ítél egy per esetén. A kernelfejlesztők most azt látják, hogy a Microsoft lefenyített egy vállalatot, aki a költséges pereskedés helyett inkább fizetett a Microsoft-nak és megkötött egy szabadalmi szerződést. Úgy tűnik, hogy a Microsoft-nak - akár igaza van, akár nincs (én ezt nem tudom) - működik ez a dolog.

A kernelfejlesztők (néhány kernelfejlesztő vagy az IBM?) ezt látva nem csináltak mást, mint nyújtanak egy lehetőséget azoknak a cégeknek, akik hasonló cipőben járnak. A cégekre bízzák, hogy termékeikben alkalmazzák-e ezt a funkciót, vagy sem. Mondhatják a cégeknek, hogy

"Szerintünk ez bullshit, ne foglalkozz vele. De ha parázol, akkor itt ez a lehetőség, kapcsold be".

Mivel a szabadalom jelenleg érvényben van, az nem biztos, hogy egy vállalatnak biztosíték, hogy Gipsz Jakab kernelfejlesztő "azt mondta".

( Egyébként nem biztos hogy meglepő ez az IBM részéről. Itt van előttem néhány IBM kassza kontroller, amin SLES9 + valami IBM stuff fut. Ezek - ha jól rémlik - olyan IBM pénztárgépekkel kommunikálnak, amik FAT32-es flash kártyára dolgoznak. Lehet hogy van összefüggés? :D )

--
trey @ gépház

esetleg a TomTom féle cégek a jövőben Gentooval szállíthatnák pl a navigátoraikat, nagy YES gombbal. első bekapcsoláskor bootstrap, teljes rendszer lefordítása. a kernel fordításánál megkérdezi, szeretnél teljes VFAT/FAT32 támogatást? ha a user lenyomja a nagy YES gombot, menjen oda panaszkodni a Microsoft:)

az viszont eléggé szánalmas, annak ellenére, hogy az EUban nincs softpatent, senki nem épít erre terméket. ennyit ér az egységes európai piac, meg úgy általában az EU.

ez OK is lenne, csak hát a távolkelet ennek ellenére képes arra, hogy fenntartson saját termékeket. GP32, GP2X, Pandora, ezeket olyan emulált játékok adták el, mint a mame. aligha lenne legális a USAban. igazából a távolkeleten sem az, csak ott a gyakorlatban szarnak a copyrightra. van is inniváció rendesen. mára le is nyomták a USA egykor egyeduralkodó it iparát, Európa meg nem is volt igazán soha sem versenyben.

ők inkább versenyképességben vernek rá amerikai és európai versenytársaikra. egy ideje elég rendesen nyomulnak mobilhálózati cuccokban.
ha a mobil ipart is ide számítjuk, akkor ott kivételesen Európa is versenyben volt. épp mostanában végzik ki magukat az európai mobil cégek. valaha szinte minden mobilterméket hálózati cuccoktól maroktelefonokig európai cégek és az amcsi Motorola uraltak, ma már lassan a Nokia marad az utolsó !távolkeleti név maroktelefonok között.

Abban a 100%-nak tekintett össz. eladásban nincs benne Ázsia. Csak Észak- és Dél-Amerika, EMEA és Ausztrália.
Abban igazad van, hogy a GP32 és társai nagyon nagy sikerek voltak. De Ázsia nagyon speciális piac...

Pl. az egyik iPhone játék eladásai így néznek ki (db/ország):

US 334,021
GB 96,978
DE 25,886
CA 25,183
FR 20,430
JP 17,401
AU 14,205
IT 8,613
NL 6,151
ES 5,945
SE 4,547
AT 3,030
NO 3,007
...stb.

Ebben az esetben world wide adatokról van szó és az össz. eladások 57% jött az USA-ból.

sok oka van annak, hogy a távolkelet ennyire nyerő informatikában. nemrég vettem egy karórába épített mobiltelefont. egy nevesincs hongkongi cég gyártatta valahol Kínában. telefonálás mellett lehet használni zenehallgatásra, és még videonézésre is. ehhez már távolkeleti szemek kellenek:) jobban megvizsgálva, egy korábbi Samsung telefon miniatürizált koppintása, némi firmware haxxolással.
nem valószínű, hogy erre lett volna szerződésük a Samsunggal és gondolom ezért sem lehet megtalálni a gyártó nevét, még a díszdobozon sem.
nem került 100 dolláromba sem. Európában meg csak néznek, még nem is láttak ilyet.

imho ázsia azért sikeres, mert nincsen ezernyi buktató az innováció útjába állítva, mint amerikában és főleg európában. a sok ígéretes innovatív projektet lelövi a jogi osztály, mert jajj mi lesz ha ezért meg azért beperelnek. ha ők nem jönnek a hozzánemértő közgazdászok, akik mindig csak a tegnap piacában képesek gondolkodni, jajj nem lesz majd piaca. a végén azoknak megy el a kedve az egésztől, akik hajtanák a fejlesztéseket.

Garmin handheld kütyük szeretik hozzáférhető, a felhasználó által leolvasható formában fájlba menteni a tracklogokat. A default mentés ÉÉHHNN.gpx névkonvenciójú, ami a 8.3-as fájlnevekkel menni is fog.

A felhasználó ettől még menthet kacifántosabb, hosszú nevű fájlba is, AFAIK, de utánanézek.

:wq

Szerintem vagyük külön egy melévő file írását, és a neveket, mert nincs igazán közük egymáshoz.
Ami nekem lejött, hogy meglévő file az olvasható, írható, mert ugyebár a file leíró az nem áll a szabadalom alatt, viszont nem hozható létre hosszú file névvel ÚJ file, csak a régi 8.3 formátum.
Ha ez olyan foltos az MS-nek, akkor hol érdekel, mi a neve a file-nak.

( tiger | 2009. 05. 07., cs – 13:20 )

ezek hülyék
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

( numen v | 2009. 05. 07., cs – 13:22 )

szvsz mindenképpen jó, mint opció a TomTom-féléknek a szuttyongatás elkerülése végett: attól még, hogy a közösség nem kapitulál, egyes felhasználók megtehetik...

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

A Tomtom eszköze mit akar írni a filerendszerre? Ha valami MYCONF.CFG (ugyebár hosszú neve nem lehet), az ilyeneket egy elkülönített 2-3 MB-os ext2 partícióra is írhatja, a többit meg megtartja a FAT-nak amit read-onlyba mountol.

Nem kell ehhez CONFIG_WE_ADMIT_LINUX_IS_ILLEGAL opció.

( Nyosigomboc v | 2009. 05. 07., cs – 14:01 )

Miert ragaszkodnak egy PNA eseteben az elavult FAT-hoz? Ott a szinten elavult, de a FAT-nal okosabb ext2, ott a jffs (direkt flash eszkozokre). Most nem teljesen mindegy, hogy a sajat, belso cucca milyen filerendszert hasznal? Ha frissiteni kell, gondolom ugyis a szamitogepet kapcsolja ossze a kutyuvel. Ha kozvetlenul akarja irni (pl. kartyaolvason keresztul), akkor meg adnak melle egy progit, amiben benne van egy ext2 olvaso (Winre is van ilyen ext2ifs neven, Linux alol meg egyertelmu).

--
"ne támogasd az erdők kiírtását mozijeggyel, töltsd le a netről!" - killllll, asva.info

1. Mert a FAT szög egyszerű, ezért az implementálása 1-2kb-nál többet nem kér a mikrokontroller flash területéről.
2. Mert így az eszköz alapban kompatibilis lesz a Win-es környezettel és a R=1 user csak rádugja a gépét a PC-re és már töltheti is fel a térképeket.
3. A legtöbb bővítőkártya VFAT formátumra van formázva alapban a 2.-es pontban említett userek miatt. PNA gyártó célja pedig a minnél nagyobb kompatibilitás elérése...

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> Ha kozvetlenul akarja irni (pl. kartyaolvason keresztul), akkor meg adnak melle egy progit, amiben benne van egy ext2 olvaso (Winre is van ilyen ext2ifs neven, Linux alol meg egyertelmu).

Azt úgy látszik elfelejted, hogy van a világon ezen a két operációs rendszeren kívül is még pár másik, és míg pl. az mtools úgy kb mindenre lefordíthatóan *már készen van*, addig ezt az akármilyen saját fájlrendszert ki kell fejleszteni, vagy ha veszünk egy meglevőt, már eleve korlátozzuk a felhasználót azzal, hogy egy *esetleg* a saját rendszere által nem támogatott formátumot használunk. Ez a FAT-ra kb egyáltalán nem igaz.

( Ewkins | 2009. 05. 07., cs – 14:28 )

Szerintem pedig el kéne most már felejteni a FAT-ot végleg, de ezzel persze feláldoznánk az interoperabilitást.

Mondjuk milyen jó, hogy a külső merevlemezeket is (igen a 1 Tb-osakat is) FAT32 fájlrendszerrel adják, mennyi gyanútlan vásárló tanulja meg első alkalommal azután, hogy nem bírja rámásolni a >4Gb-os filmeket, DVD képfájlokat, hogy mi az a fájrendszer és, hogy hogyan működik a convert parancsorból (vagy a format).

( BaT | 2009. 05. 07., cs – 14:55 )

Engem az is érdekelne, hogy a szabadalom konkrétan mit korlátoz. Hosszú filenevű fileok írását, vagy csak hosszú filenevű fileok létrehozását? És vajon létrehozásnak számít-e, ha egy 8.3 formátumú filenévvel rendelkező filet átnevezek hosszabb filenevűre?

( Csab | 2009. 05. 07., cs – 15:01 )

Komolyan olyan, mintha viccmagazinban olvasná az ember.

Ilyen balf..gokkal megy el a kernelfejlesztők ideje, ahelyett, hogy dolgoznának.

Ha szabadalmilag levédik az 1-2-3 bytesorozatot, akkor most azon fognak küzdeni, hogy a kernel sehol se írjon fájlba 1-2-3-at?

( gee v | 2009. 05. 07., cs – 18:53 )

Most ezt nem értem... ha valaki nem akar hosszú fájlneveket használni, akkor vfat helyett mountoljon msdos fájlrendszerként... nem? És akkor majd csak rövid nevei lesznek.

G

( prygme | 2009. 05. 07., cs – 19:08 )

talán szerencsésebb lenne elővenni a régi jó umsdos filerendszer supportot. márcsak azért is, mert előbb létezett mint a vfat.

( Som-Som | 2009. 05. 08., p – 13:13 )

NTFS-re milyen szabadalmai vannak a MS-nak?