Kan Microsofts filsystem exFAT lukke hullet mellem styresystemer?

24. juni 2013 kl. 16:1617
Filsystemet exFAT kan håndtere usandsynligt store datamængder, men du risikerer samtidig at miste alle dine data. Ars Technica har kigget på, om exFAT kan være fremtiden.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Teknologinyhedssiden Ars Technica har kigget på fordele og ulemper ved filsystemet exFAT med henblik på at svare på spørgsmålet: Kan Microsofts nye filsystem exFAT lukke hullet mellem styresystemerne? Det korte svar er: “Ja, men...”. For mens der er en lang række fordele, er der også ulemper.

Samlet når Ars Technica dog til konklusionen, at exFAT er en god løsning, hvis du hverken har brug for Linux-understøttelse eller vil dele en ekstern disk.

En af de mest tydelige fordele ved exFAT er evnen til at håndtere utroligt store datamængder. Men der er også udfordringer - særligt nævneværdigt er risikoen for tab af data.

Formålet med det lukkede Microsoft-filsystem exFAT, der blev introduceret i 2006, var at skabe bro mellem NTFS-filsystemet og det ældre FAT32-filsystem. En af fordelene er, at det, modsat FAT32-filsystemet, kan håndtere filer, der er større end fire gigabyte, eftersom det er et 64-bit-filsystem. I stedet har den en maksbegrænsning, der hedder 16 exabyte (2^60 bytes, også kaldet en exbibyte) og en teoretisk maksimal størrelse på 64 zettabyte (2^70 bytes, også kaldet en zebibyte).

Artiklen fortsætter efter annoncen

Apple har licenseret det lukkede format i OS X siden styresystemet Snow Leopard nåede version 10.6.5, hvor det blev muligt for Mac-brugere at formattere diske i exFAT gennem programmet Diskværktøj. Der skulle inden Apples nyeste styresystem 10.8, også kendt som Mountain Lion, ikke være problemer, som tidligere har opstået mellem kompatibiliteten mellem en disk, formateret i exFAT på Mac, men afviklet i Windows.

Men Mac-understøttelsen er ikke komplet. Ønsker man at bruge det indbyggede backupværktøj Time Machine i OS X, skal man bruge en disk, der følger HFS+-formateringen.

Linux-understøttelsen halter også gevaldigt, men det skyldes hovedsagligt, at det er et relativt nyt filsystem. Ars Technica påpeger, at der er en implementering af exFAT som et FUSE user-space level file system, men at de ikke har prøvet det.

Modsat filsystemer som NTFS eller HFS+ har exFAT en større risiko for tab af data. Dette skyldes, at exFAT, ligesom FAT32, ikke har nogen journalisering indbygget i filsystemet. Samtidig er der ingen kryptering af filer på system-niveau eller understøttelse for komprimering.

17 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
18
26. juni 2013 kl. 11:22

Jeg har en Mac med Bootcamp, og har, fordi det virkede så nemt, formateret flere eksterne harddiske til exFAT.

Jeg har faktisk ikke brugt diskene så meget, så jeg ved ikke, hvordan filerne har det.

Nu har jeg læst artiklen på Ars og sidenhen her, og nu tænker jeg - hvordan vil jeg eventuelt opleve det datatab, der tales om?

Altså, helt konkret - hvad vil der ske? Vil filer pludselig bare være ubrugelige, uden nogen chance for at redde dem?

Og hvordan ville det ikke ske eller kunne reddes med NTFS eller andre formater? :)

14
25. juni 2013 kl. 10:49

Er problemet ikke at Microsoft vil udnytte sin markedsdominans?

De udnytter, at langt de fleste har Windows til at tvinger folk til at bruge FAT eller exFAT, som producenterne af kamararer med mere så skal ud og købe licenser til. Der finder jo netop mange gratis (ikke patenterede) udemærkede filsystemer, som fungere på samtlige platforme, som producenterne og Microsoft og Apple bare kunne bruge. Det eneste, som forhindrer denne vej er at Microsoft ikke vil, da de netop vil have licenser til deres filsystemer.

10
25. juni 2013 kl. 07:02

Der refereres flere gange til det, som et "nyt" filsystem. Jeg ved ikke lige hvad de mener med "nyt", men jeg har brugt det i mindst 5 år, og når det kommer til filsystemer, er jeg aldrig blandt de første, til at tage det til mig.

4
24. juni 2013 kl. 18:41

...NTFS den bedste løsning, det er understøttet både på Windows, Linux og OS X. Det har samme licens/patant problemer som exFAT men har til gengæld journalisering.

13
25. juni 2013 kl. 09:30

NTFS har kun læseunderstøttelse i OS/X. Men det er muligt at købe ekstra programmer som i følge deres reklamer er i stand til at give understøttelse. Men om det er rigtigt skal jeg lade stå usagt.

Hvis du læser den originale artikel så står der også noget om NTFS. Jeg har brugt Tuxera NTFS og det har fungeret uden problemer. Ifølge artiklen så performer Tuxera ikke lige så godt som Paragon NTFS og Paragon er desuden billigere.

5
25. juni 2013 kl. 00:03

NTFS den bedste løsning, det er understøttet både på Windows, Linux og OS X.

NTFS er ikke godt nok til Linux. Den samlede længden af sti og filnavn må max. være 256 tegn under NTFS. På et linux filsystem, må hvert led være op til 256 tegn. Det skaber tit problemer i virkeligheden.

Her er en lille liste over ting, der er muligt på et Linux filesystem, men ikke under NTFS.

En fil, der hedder "A" og en der hedder "a" i samme katalog.

Filerne, der hedder nul lpt1 con K. a:b prn com1

15
25. juni 2013 kl. 12:31

Den samlede længden af sti og filnavn må max. være 256 tegn under NTFS.

Jo det kan den godt. http://en.wikipedia.org/wiki/NTFS#Limitations

En fil, der hedder "A" og en der hedder "a" i samme katalog.

Det kan du også med NTFS. Case sensitive file naming er bare ikke default ved en Windows install.

Filerne, der hedder
nul
lpt1
con
K.
a:b
prn
com1

Jeg betvivler din påstand. Hvorfor skulle NTFS blokere dette? Jeg kan forstå at Windows ikke kan lide det, men at dette skulle være pga. NTFS har jeg stor tvivl omkring. Har du noget dokumentation?

12
25. juni 2013 kl. 09:08

NTFS er ikke godt nok til Linux.
Den samlede længden af sti og filnavn må max. være 256 tegn under NTFS.

260 godt nok, men ja. Det er ikke en begrænsning i NTFS (som understøtter 32k lange filnavne), men i Win32-APIet. Den kan omgås på absurd vis ved at benytte deres unicode-API og samtidig sætte strengen "\\?\" foran navnet :p. Desværre gør Windows det ikke selv i hverken explorer eller cmd eller andre steder, så det er i praksis stort set ubrugeligt.

Her er en lille liste over ting, der er muligt på et Linux filesystem, men ikke under NTFS.</p>
<p>En fil, der hedder "A" og en der hedder "a" i samme katalog.</p>
<p>Filerne, der hedder
nul
lpt1
con
K.
a:b
prn
com1

Det er igen begrænsninger i Win32 og ikke NTFS. De kan også undgås på samme måde som ovenstående, omend med samme effekt (nemlig at man så ikke kan håndtere filerne korrekt i Windows' egne tools).

Heldigvis har vi med Windows 8 endelig skiftet til WinRT som ikke har...nå nej, det er stadig baseret på Win32 på trods af Microsofts antydninger om det modsatte ;).

11
25. juni 2013 kl. 08:49

NTFS er ikke godt nok til Linux.
Den samlede længden af sti og filnavn må max. være 256 tegn under NTFS.
På et linux filsystem, må hvert led være op til 256 tegn.
Det skaber tit problemer i virkeligheden.

Jeg sagde det er det bedste alternativ som er nogenlunde supporteret på alle 3 OS'er det var ikke ment som "ideel løsning". Jeg kan f.eks. konsekvent ikke læse andet end directoryet på en exFAT i min favorit Linux.

Her er en lille liste over ting, der er muligt på et Linux filesystem, men ikke under NTFS.

NTFS "kender" forskel på store og små bogstaver, det er Windows som ikke gør det... det samme problem har man hvis man mounter en ext2 disk under Windows (ja, det kan man godt med en lille utility som hedder win2ext).

lpt1, prn, con, com1, nul er device navne i DOS og nedarvet til Windows og det er a: også, det svarer til at lave en fil med navnet sda i /dev når den første hd hedder sda. Ja, det er skod men de samme begrænsninger er på alle filsystemer under Windows.

8
25. juni 2013 kl. 02:25

NTFS er ikke godt nok til Linux.
Den samlede længden af sti og filnavn må max. være 256 tegn under NTFS.
På et linux filsystem, må hvert led være op til 256 tegn.
Det skaber tit problemer i virkeligheden.

Et godt eksempel er DVB PVR boxe hvor filnavnet genereres ud fra udsendelsens navn. Nogle gange indeholder udsendelsens navn tegnet ":" eller lignende som ikke er tilladt på Windows. Der virker fint med NTFS driveren på Linux PVR boxen, men så flytter folk USB disken fra PVR boxen til en Windows computer..

Jeg havde lidt af det samme problem dengang jeg i en overgangsperiode på Windows-afvænning kørte Windows-Linux dual boot med en delt data partition ("Dokumenter") formatteret som NTFS. Linux driveren accepterede filnavne som ikke var tilladte på Windows (selvfølgelig en Linux bug).

7
25. juni 2013 kl. 00:11

NTFS er ikke godt nok til Linux.

Kravet er ikke at det skal være godt nok til Linux. Det skal være godt nok til et kamera eller et TV med optagefunktion eller tilsvarende. NTFS er fint men performer ikke ret godt hvis man forlanger at det skal kunne overleve at få mediet hevet ud uden varsel. Lige præcis der er FAT (med et sæt regler om hvad man opdaterer først) faktisk ret godt.

1
24. juni 2013 kl. 16:55

Ars Technica tager fejl. Linux-understøttelsen mangler ikke pga. at filsystemet er nyt. Grunden er at det er patenteret. Der kommer ikke officiel Linux-understøttelse før patenterne er løbet ud, dvs. om ca. 15 år.

6
25. juni 2013 kl. 00:07

Hvad med en version af Linux for lande, der ikke anerkender software-patenter ?

Jeg nægter altså at flytte til New Zealand for at bruge exFAT. Det står endda ikke helt klart at New Zealand faktisk kan undgå softwarepatenter i praksis. Så hvilken relevans ville det have?