Teljes r/w támogatással működik a Windows XP NTFS drivere a ReactOS-ben

Open Source

Afféle karácsonyi meglepetésként jelentette be a ReactOS projekt, hogy az Windows XP-ből átmásolt NTFS driver teljes írás/olvasás támogatással működik immár a ReactOS-ben.

( goodbyte v | 2020. 12. 27., v – 09:45 )

Kicsit mintha felgyorsultak volna arrafelé a dolgok!

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

( ST0NE | 2020. 12. 27., v – 10:08 )

Ezt most nem értem miért jó. Nem az a cél hogy ők implementaljanak mindent? Miért jó hogy atmasoljak?

( nullptr | 2020. 12. 27., v – 11:34 )

A végén még lesz belőle valami.

Psszt, elárulom az IP-címemet: 192.168.0.14

( Pene | 2020. 12. 27., v – 21:52 )

Szerkesztve: 2020. 12. 27., v – 21:55

Félig off: Épp anyámék okostévéje nem akarja megenni az exfatot. De az ntfs-t kajálja.

( Ligend | 2020. 12. 28., h – 16:23 )

A verziószám alapján ez inkább 32 bites Windows Server 2003-ből származó NTFS driver, mintsem XP-ből. A screenshot szerint a ReactOS is NT 5.2 SP3-nak jelenti magát, vagyis ez már nem is XP, hanem Server 2003 klón. :)

( arpi_esp v | 2020. 12. 28., h – 17:19 )

hat en meg arra emlexek, hogy ugy 15 eve meg ugy lehetett linux alatt ntfs-t irni, hogy valami hack a windozos ntfs dll-t hasznalta linux alatt wrapperkent (aztan jott az ntfs-3g). ehhez kepest eleg sokara sikerult eljutniuk erre a szintre...

Ha úgy nézzük, hogy 15 éve a Linux kernel első kiadása 14 éves volt, a ReactOS első kiadása pedig 2 éves (a ReactOS 0.1 2003 februári), akkor azért annyira nincs lemaradva.

Bár a linux fejlesztése mögött töb pénz és fejlesztő van, így nyilván nem versenyezhetnek egymással. Az NTFS-3G fejlesztésén is többen dolgoznak, mint ReactOS alatt az összes támogatott fájlrendszeren együtt. ( https://reactos.org/wiki/People_of_ReactOS )

Nagy Péter

Azért a Linux sem volt jó szinten ebben, az nfts-3g egy userland driver, csomó mindent nem tud (defrag, normális chkdsk-s javítás), óriási az overheadje. Nem véletlen, hogy az 5.12-es Linux kernelbe is érkezik majd egy új, teljesebb rw driver, ami már kernelspace-ben fut, kiküszöböli a hiányosságokat. Elvileg ezt a Paragon szállítja, nem az XP source code leak-ből szedik, de ennek ellenére egyébként lehet összefüggésben, hogy a code leak miatt nyitja meg a Paragon a saját implementációját. Ennek ellenére én mindig úgy voltam vele, hogy aki komolyan linuxozik, ne használjon NTFS-t. Nem csak azért, mert szuboptimális, meg zárt, hanem egy lassú, szutyok, elavult fájlrendszer, amire a modernebb linuxos fájlrendszerek mind tudásban, mind sebességben köröket vernek. Még különböző OS-ek között megosztott meghajtókra is érdemesebb exfat-ot tenni inkább.

A ReactOS fejlesztőgárva viszont garantáltan a code leakből dolgozik, amiért szerintem meg fogják ütni a bokájukat egy idő után, ha a MS megelégeli.

“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.”

Ja, és most a code leak után lendült be igazán a projekt, így hirtelen, jó egy évtized múlva, csak úgy záporoznak azóta a hírek, hogy végre megy ez, megy az. Nyilván a MS is hülye, és nem fogja kiszúrni. A helyükben én is ezt mondanám, hogy saját kútfő. Persze én nem ítélem el őket, csak nem szeretem a kamuzást. Nem vagyok híve se a MS-nak, se a Windowsnak, se az NTFS-nek, de az pl. nekem is jól jön, ha a jövőben egy NTFS-es meghajtót rendbe tudok tennni Linux alatt, és nem kell azért átbootolni Windowsra, szóval szurkolok a projektnek, csak csinálhatnák a dolgokat kevésbé feltűnően.

“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.”

( mrev | 2021. 01. 05., k – 21:29 )

Szerkesztve: 2021. 01. 05., k – 21:32

Sok baja van az NTFS-nek, de mondjuk a legegyszerűbb, hogy UTF-16-ban tárolja fájlneveket. Emiatt C szinten két párhuzamos API kell a fájlművetelekhez: egyikben szimpla karakterekkel lehet megadni a fájlneveket, a másikban széles karakterekkel.  Bődületes fasság. Az NTFS és az UTF-8 kódolás is 1993-ban mutatkozott be. Ha várnak 1-2 évet az NTFS-sel, akkor elkerülhették volna ezt a tervezési hibát, ami miatt most évtizedekig szenvedhetünk. A DOS-Novell világból természetesnek tűnő örökség volt, hogy a Windows sem engedi törölni a nyitott fájlokat. Valójában ez egy primitív hülyeség, ami miatt a Windowsban nem lehet megcsinálni a normális frissítést. Inkább el kéne az egészet felejteni.

Lógok a szeren (K. Frigyes)

Lógok az ereszen (Sz. József)

Sok baja van az NTFS-nek, de mondjuk a legegyszerűbb, hogy UTF-16-ban tárolja fájlneveket. Emiatt C szinten két párhuzamos API kell a fájlművetelekhez: egyikben szimpla karakterekkel lehet megadni a fájlneveket, a másikban széles karakterekkel.

Miért, ha ext4-et vagy btrfs-t használsz UTF-8-cal akkor nem a wchar API-t használnod? Az a fájlrendszer magánügye, hogy milyen kódolást használ, ez az API szempontjából teljesen irreleváns. Azért van az fs driver, hogy ezeket a különbségeket elfedje.

Hol van ebben wchar?

Feltételeztem, hogy széles karakterek alatt wchar-t értesz.

Két párhuzamos fájl API van.

Mármint Windowson? Mert a Win32 API-ban valóban van egy *A és egy *W variáns (pl. CreateFileA és CreateFileW). De ennek semmi köze ahhoz, hogy az NTFS UTF-16-ot használ, bármelyik függvényt használhatod bármilyen fájlrendszerrel.

Az open ezzel szemben char *-t vár, amit a hívónak kell megfelelően kódolni. De nem látom akadályát annak, hogy a hívó a fájlnevet UTF-8 kódolással adja át, amit az NTFS driver átkódol UTF-16-ra. Persze ez csak akkor működik, ha a driver tudja, hogy milyen kódolással fogja megkapni a fájlnevet.