Apple gaat voor flashgeheugen geoptimaliseerd Apple File System gebruiken

Apple heeft een nieuw bestandssysteem aangekondigd dat gebruikt gaat worden voor iOS, macOS, tvOS en watchOS. Het bestandssysteem is volgens Apple geoptimaliseerd voor flashgeheugen en encryptie.

Apple File System is te gebruiken als een Developer Preview in macOS 10.12 Sierra en moet in 2017 uitkomen. Uiteindelijk wil Apple dat ook iOS, tvOS en watchOS op het bestandssysteem gebaseerd worden. De fabrikant meldt op het WWDC dat het bestandssysteem geoptimaliseerd is voor gebruik in combinatie met flashgeheugen of ssd's en functionaliteit als 'sterke encryptie', copy-on-write metadata, space sharing, klonen van bestanden en mappen en snapshots biedt.

Op een pagina zet Apple de verschillen van APFS ten opzichte van HFS+ op een rij. HFS+, dat Apple nu gebruikt voor OS X, is gebaseerd op het dertig jaar oude Hierarchical File System. Zo gaat APFS 64bit inode numbers ondersteunen in plaats van 32bit. Ook ondersteunt het bestandssysteem in tegenstelling tot HFS+ asynchrone trim-bewerkingen bij het verwijderen van bestanden en vrijmaken van opslagruimte.

Wat encryptie betreft ondersteunt APFS singlekey- en multikey-encryptie met aparte keys voor data van bestanden en voor metadata. Apple gaat aes-xts of aes-cbc gebruiken, afhankelijk van de hardware.

Er zijn nog wel enkele struikelblokken voor het gebruik. Zo kan APFS nog niet voor opstartschijven gebruikt worden, zijn bestandsnamen nog case-sensitive, worden back-ups van Time Machine nog niet ondersteund, kunnen volumes nog niet met FileVault versleuteld worden en kan het bestandssysteem nog niet overweg met Fusion Drives van Apple-computers.

Reacties (118)

[Maurits van Baerle]

Een mooie ontwikkeling dit, en iets waar veel mensen lang en luidruchtig op hebben zitten wachten. Helaas dat het zover heeft moeten komen aangezien Apple al redelijk gevorderd was met de implementatie van ZFS totdat Sun door Oracle gekocht werd. Nu komen via APFS een aantal filosofieën uit ZFS alsnog in macOS terecht.

Het enige wat ik nog mis in het rijtje met features, en waarvan ik toch echt hoop dat het op termijn wordt toegevoegd, is het gebruik van checksums om je data te beschermen tegen bitrot.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 23:29]

[Verwijderd]

Hoe beschermt een checksum daartegen? Als je bestand corrupt is, dan is deze toch corrupt? Een bevestiging dmv checksum helpt je dan toch niet uit de brand? Mis ik iets?

[Maurits van Baerle]

Kijk maar eens hoe ZFS checksums gebruikt. Aardig leesvoer https://blogs.oracle.com/bonwick/entry/zfs_end_to_end_data

[satoer]

Ik zou het pas een mooie ontwikkeling vinden als het een open standaard zou worden. Het was al gedoe om externe Apple schijven te lezen op Windows. Nu heb je hier nog 3rd party drivers voor, dat zal wel meer zeuren worden met dit nieuwe bestandssysteem.

[Maurits van Baerle]

Open Source

An open source implementation is not available at this time. Apple plans to document and publish the APFS volume format when Apple File System is released in 2017.

Open Source

Een Open Standaard lijkt het te worden dus. Nu nog even afwachten of ze de implementatie ook publiceren of dat mensen hun eigen implementatie moeten schrijven op basis van de standaard.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 23:29]

[Verwijderd]

Microsoft die voor Windows dadelijk het "Apple File System" gebruikt, voer voor een heerlijke troll, als je het mij vraagt.

[Verwijderd]

Microsoft zal eerder voor het eigen ReFS gaan. https://en.wikipedia.org/wiki/ReFS

[gjmi]

Andersom zou ik ook wel willen dat NTFS een open standaard zou worden.

[Verwijderd]

Dat laatse is juist het hele punt van zfs. Zfs zonder checksums is een auto zonder motor zeg maar. Raar dat ze dat niet meenemen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 23:29]

[Maurits van Baerle]

Het zit nog niet in de alpha maar wat niet is kan nog komen.

[field33P]

Dat is ook een van de dingen die ZFS zwaarder maakt.

[Maurits van Baerle]

ZFS wordt vooral veel zwaarder als je Dedup aan zet. Zonder Dedup is het nog best te doen.

[DigitalExorcist]

Checksums beschermen je niet tegen bitrot, toch? Het signaleert alleen en meldt dit waarschijnlijk. Regelmatige back-up- en restoretests beschermen een stuk beter.

[Maurits van Baerle]

Het probleem is dat backups juist vaak niet helpen. Je kunt doodleuk al een jaar een bestand met één of twee geflipte bitjes backuppen.

Het idee van een checksum is nou juist dat je meteen kunt vaststellen of er iets mis is gegaan met lezen of schrijven van een block en misschien zelfs automatisch herstellen. Mocht het niet te herstellen zijn kun je het uit een oude backup halen voordat het kapotte bestand je goede backup overschrijft in de volgende backup ronde.

[BeosBeing]

Leuk,

Zo gaat APFS 64bit inode numbers ondersteunen in plaats van 32bit.

Dit hadden ze 16 jaar geleden al kunnen hebben als men destijds met BeOS in zee was gegaan. Dat draaide eerst ook alleen op Apple hardware, maar omdat de deal niet doorging is BeOS to naar Intel geport, iets wat Apple later zelf ook met OS-X deed.

Uiteraard zat dat wat men nu uit ZFS overneemt destijds niet in BeFS. Nu dit nog kunnen lezen vanuit Windows, Linux en xBSD, maar daar zit Apple waarschijnlijk niet op te wachten (lees: claims). Men zal zijn eigen unieke features boven universaliteit stellen. Cross-platform blijf je dus afhankelijk van NTFS, FAT of UDF 1.5

[MajorMuff]

Wat is er precies mis met hooflettergevoelige bestandsnamen?

[HunterPro]

Dat sommige bedrijven (bijvoorbeeld Adobe) enorme applicaties hebben gebouwd die het niet doen als je filesystem hoofdlettergevoelig geformatteerd is. Ya, really. https://helpx.adobe.com/c...ive-drives-supported.html

[readefries]

Dat geeft niet aan wat er mis is met hoofdlettergevoelige bestandsnamen, maar meer over het ontwikkelproces bij Adobe...

[Annihlator]

Ja maar voor apple is omgekeerde-logica wel vaker logisch.

Kijk maar naar dat ze elke tegengestelde instelling t.o.v. normale OS'en "natuurlijk" noemen

[CAPSLOCK2000]

Het verbaast me, ik zou het juist meer iets voor Apple vinden om de softwareboeren te dwingen zich aan te passen aan het nieuwe systeem.

Het wordt ook steeds belachelijker om nog een case-insensitive filesysteem in leven te houden. Alle moderne OSen zijn case-sensitive. Het wordt wel erg gek als je filesysteem wel UTF-8 spreekt en de meest gekke vreemde tekens kan gebruiken maar niet overweg kan met het verschil tussen hoofdletters en kleine letters.

[keranoz]

Alle moderne OS'en zijn case sensitive? Windows is dus niet modern? Voor Windows is immers "Bestand" hetzelfde als "bestand"

[MtC]

Windows is inderdaad niet modern. Zeker wat betreft het filesystem dat al dateert van Windows NT 3.1.

[Blokker_1999]

En toch heeft het onderliggende NTFS ondersteuning voor case sensitive bestands- en foldernamen

[PPie]

Voor Windows is immers "Bestand" hetzelfde als "bestand"

Het is zelfs erger. Explorer.exe laat soms filenamen zien die er qua case niet eens zijn. Keer ingestonken, de directory was volledig in hoofdletters (zeg ABCD), maar Explorer.exe maakte daar 'Abcd' van. En die kon de tooling echt niet vinden op het case-sensitive filesysteem...

[biteMark]

Ben ik niet met je eens. Uit technisch oogpunt zou er inderdaad onderscheid gemaakt moeten worden, maar voor gebruikers kan het erg verwarrend zijn als er verschillende bestanden met dezelfde naam zij (afgezien van hoofdlettergebruik). Dit geldt des te meer als er met hoofdletters wordt gespeeld in bestandsextensies terwijl de gebruiker ervoor kiest om die niet zichtbaar te maken - zo zie je geen verschil tussen photo.jpg, photo.JPG, photo.JpG etc.

[Sando]

Gewoon nieuwschierig: Heb je ooit in je leven een .JpG bestand gezien?

[biteMark]

Nee, maar het gaat erom dat het in theorie mogelijk is en dat er verwarring kan ontstaan bij gebruikers

[supersnathan94]

is het niet verwarrender dat een .jpg onderwater exact hetzelfde is als een .JPg of .jpG? ik vind namelijk van wel. taal heeft niet voor niets hoofdletters. zonder zien teksten er niet uit.

[Sando]

Dat is niet juist. Het is onderwater niet het zelfde. Het is juist boven water hetzelfde; Windows werkt hoofdletter-agnostisch, en gaat er van uit dat je gewoon hetzelfde bedoeld.

Bewijs-experiment: Mount een NTFS-schijf in linux, en maak twee bestanden aan: hoi.txt en hoi.TXT.

Boot weer in Windows, en je kan ze allebei zien en bewerken.

[Reactie gewijzigd door Sando op 24 juli 2024 23:29]

[supersnathan94]

Ja maar ho ff. Het kan best zijn dat Linux een shitload aan extra info toevoegd die jij niet zomaar kan zien, maar windows wel herkent. Linux is daarnaast wel case sensitive en zal daar dus truukjes voor hebben om dergelijke dingen ook op te slaan op file systems die dit niet native hebben.

[Sando]

Ik denk dat Linux en filesystems een black box voor je zijn en dat je daarom aan denkt aan een 'shitload' aan geheimzinnige extra info. Want dat is niet zo. Linux heeft zich gewoon te houden aan de Microsoft Windows NTFS interface. De bestandsnaam staat gewoon in de MFT.

Maak in Windows hoi.txt en HALLO.txt aan, rename ze in Linux naar HOI.txt en hallo.txt, en in Windows zie je het resultaat.

[Sando]

Alle moderne OSen zijn case-sensitive.

De twee grootste, Windows 10 en OS X, zijn dat niet. Van de noemenswaardige marktaandeel-systemen is eigenlijk alleen Linux case-sensitive. En da's ouder dan Windows en OS X, de minst moderne van de top 3. En "niet overweg" kunnen met het verschil is ook wat flauw; tegenwoordig in het UTF tijdperk wordt gewoon extra moeite wordt gedaan om deze case-insensitivity te preserven. Het is een feature, geen gebrek. Een goed verhaal is dus anders.

Maar ik snap je je wel: Je wilt zeggen dat elk zichzelf respecterende besturingssysteem gewoon case-sensitive is, en dat ben ik met je eens.

[supersnathan94]

Het scrollen in windows is het eerste mij direct opvalt als zijnde raar. Op een touchscreen beweeg ik de pagina omhoog als ik wat verder naar beneden wil lezen, maar met een touchpad trek ik het venster/view naar beneden terwijl het document blijft staan. En omdat dat venster niet naar beneden kan gaat het document maar omhoog.

Het is toch juist heel logisch dat als je naar beneden wil je dan de zooi die er boven zit naar boven schuift?

[ToFast]

Heeft dit niet te maken met de implementatie van de drivers van je touchpad van je Windows laptop ? Kan me voorstellen dat het bij andere touchpads of fabrikanten omgekeerd is. Je bedoelt wat anders denk ik. Dit heeft te maken met het sleutelwoord directe manipulatie en touchscreens. De meest 'directe' vorm van directe manipulatie is het touchscreen icm je vinger. Een tussenvorm zie ik dus als het touchpad en de muis. Het lijkt wat gek dat touchscreen manipulatie en die van een touchpad omgedraaid zijn in geval van scrollen, maar hier is goed over nagedacht. Er is vast iemand die dat beter kan uitleggen, maar het heeft allemaal te maken met user experience / usability.

Anyways, in Windows of mac os kan je dit vast wel omdraaien in de instellingen.

[Reactie gewijzigd door ToFast op 24 juli 2024 23:29]

[Verwijderd]

Klopt, in beide OS'en kun je de richting van schollen aanpassen.

[Werelds]

Het is maar net wat je gewend bent. Ik heb Apple's "natural" scroll uit gezet omdat ik het juist onnatuurlijk vind

Je kunt het sowieso al jaren omkeren. De meeste fabrikanten leveren software mee om dat te doen (niet in het minst MS; die deden dat 15 jaar geleden al met de Intelli's ) en als "last resort" zit het ook gewoon in het register.

[ThomasG]

Als je enkel een muis gebruikt is de natural scroll wellicht niet het meest handige. Bij een trackpad is het echter juist wel natuurlijk. Als je op een Smartphone of Tablet en touchscreen door bijvoorbeeld een web-pagina scrolled, dan pak je de pagina beneden aan het scherm vast, en swipe je naar boven. Dat doe je niet door boven aan het scherm naar beneden te swipen, om vervolgens de pagina omhoog te zien gaan. Bij de natural scroll in OS X duw je in feiten de web-pagina omhoog om naar beneden te scrollen, netzoals op een touchscreen. Dat is logisch en werkt heel natuurlijk, als je daar eenmaal aan gewent bent wil je niet meer zonder. Bij een muis met scrollwheel werkt dat dan iets minder handig. Echter werkt een muis sowieso erg onhandig in OS X, omdat je daarmee veel features die je met het trackpad kunt benaderen dan niet kunt gebruiken, en minder productief bent. Het is wellicht persoonlijk, maar ik vind de trackpad van een MacBook veel beter dan een willekeurige muis.

[Werelds]

Dat is inderdaad gewoon heel persoonlijk.

Ik werk nog steeds sneller met een muis dan met een trackpad en ook met een trackpad vind ik de "oude" manier nog steeds natuurlijk omdat ik m'n trackpad niet als touchscreen beschouw. Voor diegenen die vooral met touchscreens zijn begonnen is het vast andersom, omdat die hun trackpad als spiegel van het scherm beschouwen, terwijl het voor mij gewoon een muis is. Dus omlaag scrollen betekent dat ik verder naar beneden in het document wil zien, niet dat ik het document omlaag wil "slepen" zoals dat bij touchscreens het geval is

Wat productiviteit betreft ben ik het ook niet met je eens, ook dat hangt er maar net van af wat je gewend bent. Ik ben ooit begonnen met DOS en als programmeur heb ik m'n handen vooral op het toetsenbord dus toetsencombinaties zijn voor mij veel sneller. Stukje tekst selecteren, knippen/kopiëren en plakken of een regel verplaatsen doe ik allemaal met het toetsenbord. Applicatie starten? CMD + Spatie of Windows toets en typen wat ik wil hebben. Exposé/MC/LP gebruik ik ook niet, ik CMD/ALT + TAB, is veel sneller. En het bureaublad? Dat fungeert alleen als een tijdelijke opslag plaats omdat zowel Windows als OS X daar altijd fijn een snelkoppeling voor hebben gehad. Ik ga toch niet alles minimaliseren om een snelkoppeling te zoeken

Andere desktop? CTRL + pijltje. Notificatie balken in zowel OS X als Windows gebruik ik ook niet. Het enige waarvoor ik echt naar de trackpad zou grijpen als de applicatie het überhaupt ondersteunt is roteren. Zoomen ook wel, hoewel CTRL + scroll wiel net zo rap is.

[Annihlator]

^ Dit.

Het gaat mij niet om wat "juister" (door die suggestieve verwoording) of "natuurlijker" is, doe als OS-ontwikkelaar niet zo onzinnig om te pogen daar gebruikers mee af te leiden/bij te sturen. Houd het gewoon neutraal in de verwoordingen van je configuraties en respecteer dat sommige mensen andere dingen simpelweg handiger vinden werken. Daar hoeft geen indirect suggererende verwoording bij te hangen invoervoorkeuren zijn nou eenmaal (meestal) niet zwart-wit, zeker als je er bij stil staat dat sommigen bijvoorbeeld liever een trackball of een wacom-pen gebruiken

[Sando]

Dit blijft persoonlijk. Sommige mensen zien een touchpad als een touchscreen. Anderen zien dit als een passe-partout/viewport die je over de webpagina beweegt.

Je had/hebt precies het zelfde bij 3d shooters. Voor early gamers, die nog zijn opgegroeid met EF2000, Wing Commander of Privateer 2, is het heel natuurlijk dat je de joystick/muis/cursor omlaag stuurt om je neus omhoog te laten gaan.

Deze gamers hebben die voor hen natuurlijke besturing meegenomen naar 3d shooters waarbij je met de muis omlaag beweegt om omhoog te kijken.

Nieuwe gamers die niet eens weten wat Wing Commander is hebben dit nooit begrepen en voor hen is dit compleet onnatuurlijk. Deze twee groepen zijn het nooit eens kunnen worden, en ze hebben allebei gelijk. Van daar dat elk spel een "Invert vertical mouse look" optie heeft. En nu, 20 jaar later, nog steeds.

[Verwijderd]

Ik vind het ook niet handig, maar mijn kinderen die zijn opgegroeid met touch screens vinden de "normale" methode niet normaal. Die zetten allemaal natural scroll aan.

[Werelds]

Dat is dus precies wat ik bedoel. Het is maar wat je gewend bent

[xFeverr]

Je beweegt de scrollbar toch naar beneden? Sowieso is een touchscreen een heel ander invoerapparaat waarbij je andere eisen en wensen hebt. Dan moeten we vervolgens niet datgene wat normaal is voor een touchscreen opeens normaal gaan vinden voor een muis. Dat werkt niet, net als dat andersom ook niet werkt...

[Verwijderd]

Voor een muis voelt het misschien raar aan, zeker als deze een fysieke scrollwheel heeft. Maar op een touchpad voelt het wel natuurlijk aan, juist omdat deze handbeweging vergelijkbaar een pagina omhoog duwen op een touchscreen. Het lijkt me meer gewenning, omdat je al decennia het tegenovergestelde doet en nog denkt dat je een scrollbar bedient. Wel wordt het vervelend als je vaak van werkplek/machine verandert en de instelling elke keer een verrassing is.

[xFeverr]

Mijn fout, het ging inderdaad over een touchpad. Dat is inderdaad wel logischer.

Standaard is dit ook volgens de manier zoals Apple dit doet. De standaard drivers die bijvoorbeeld de surface producten gebruiken doen het op deze manier. Helaas heeft zowat elke andere fabrikant eigen drivers en software die het dan weer anders doen

[supersnathan94]

Valt opzich mee. Ik verander nog wel eens van systeem omdat ik op het werk zowel met ubuntu als met OSX werk. Ik moet zeggen dat het me nog niet is opgevallen dat het anders werkt, het valt wel op dat OSX veel vloeiendere scrollbewegingen maakt met het touchpad dan andere OS-en met een free floating scrollwheel.

[supersnathan94]

Ik heb het netgens over een muis. Ik heb het over een ander touch apparaat: een trackpad (trackpad op een macbook is overigens vergelijkbaar met een touchscreen. Sterker nog. Het is hetzelfde systeem als wordt gebruikt in de iPhone.

[Annihlator]

Precies het voorbeeld waar ik op doelde het verschil tussen hoe de meesten een scrollwiel relateren aan het scroll-element dat je omlaag duwt en bij het touchscreen dat je de gehele pagina verplaatst

Er zijn bar weinig macs met een touchscreen, maar worden standaard geleverd met een 'mighty-mouse'.
Ik vind in de volgende ontwikkelingen mooie tegenstrijdigheid zitten dat zij vervolgens een touchpad ín die muis bouwen en door de assumptie dat iedereen de mac dan ook met DIE muis gaat besturen bepaalde keuzes voor U.I. besturing als "natuurlijk" zijn gaan bestempelen, wat potentieel foutief kan zijn (het is iig argumentabel van beide zijden) en 'geïnverteerd' of 'omgekeerd' had simpelweg geklopt.
(Beter gezegd; de verwoording "Natuurlijk" kan enkel kloppen wanneer je het hebt over touchscreen/pad-besturing en de mighty-mouse)

In mijn ogen is het omgekeerde-logica, omdat er een eenduidigere (en zodoende, m.i. logischere) keuze had geweest.

Daarnaast zou ook het doen beweren dat iedereen die niet een touchscreen, touchpad of mighty mouse gebruikt al snel "onnatuurlijk scrollt" wat zéker niet hoeft te kloppen en het is daar buiten ook nog eens erg moeilijk te discussiëren over wanneer zo'n verwoording "klopt". voor omgekeerd hoef je alleen een (voor jouw systeem/programma) basiswijze te hebben die deze omkeert, zeer eenduidig.

[Verwijderd]

Vroeger scrollden mensen met een scrollwieltje. Het touchpad is dit gaan emuleren. Echter sinds touch screens gemeengoed werden zijn meer en meer mensen touchpads hetzelfde gaan gebruiken als touch screens. Daarom kun je de scroll richting voor touchpads tegenwoordig omdraaien.

[supersnathan94]

Hoelang is "tegenwoordig"? Ik weet niet of dit een standaard windows instelling is of een drivers aanpassing. Ik weet dat het in windows zeven niet kon.

[Verwijderd]

Tegenwoordig betekent nu. Hoe lang dat al zo is, heb ik geen idee van. Is dat relevant? Op mijn Asus Transformer is het een driver instelling. Standaard scrollt het touchpad als een touch screen. Ik heb het echter aangepast naar scrollen als scrollwieltje omdat ik dat al van lang geleden gewend ben. Afwisselend scrollen met pad en screen is voor mij zo ook helemaal niet verwarrend.

[supersnathan94]

Dit is relevant omdat "tegenwoordig" op OS X al vier-vijf jaar is. Daarnaast is het dus een driver aanpassing waar windows zelf niets mee te maken heeft. De driver invert gewoon de input als hij denkt hee je bent aan het scrollen. Scrollen dmv scroll bar naar beneden trekken (dat is wat het wieltje doet) is al jaren niet echt relevant meer doordat veel UI's deze balken al niet meer standaard laten zien (zoals in windows XP en 98 enzo wel het geval was). Alleen als je iets scrollt wordt een overlay zichtbaar om te laten zien hoe ver je kan scrollen.

Het hele idee wat Apple heeft gehad met het touchpad werkt juist daarom ook zo goed. Door hier ook daadwerkelijk een touchscreen van te maken werkt deze al vele jaren velen malen beter dan eender welke fabrikant en staan ze alom bekend als de beste trackpads die er zijn. Alleen Dell komt momenteel heel erg dichtbij in de xps series, maar ook die vind ik zelf nog net niet goed genoeg in verhouding met mijn force touch trackpad. De gevoeligheid en precisie van dat ding is echt ongeevenaard en laat het gemis van een touchscreen kompleet achterwege.

[HunterPro]

Netto moet je dus een hoofdletter-ongevoelig filesystem hebben wil je Photoshop kunnen gebruiken. Wiens schuld het is is een non-discussie.

[Verwijderd]

Ben zelf toevallig laatst tegen dit probleem aangelopen. Ik heb zelf geen Mac dus was ook niet van dit probleem op de hoogte natuurlijk. Ik kon het bijna niet geloven. Wanneer leven we, 1985?! Manmanman...

Afgezien daarvan, 'even' wat op een Mac installeren met bijna uitsluitend kennis van Windows is sowieso bepaald geen sinecure.

[supersnathan94]

Even wat installeren op een mac is een eitje. Sleur en pleur heet dat. Voor al het andere spul zijn er installers die vrijwel altijd dezelfde interface hebben.

[v0LrAtH]

Probeer dan maar eens een bestand te renamen dat identiek is, en enkel qua "hoofdlettergebruik" scheelt. Zeker met diverse versioning systemen geeft dit serieuze issues.

We hebben er letterlijk een half uur geleden weeral met 4 developers op liggen vloeken.

Het is dus juist een enorm voordeel van hoofdlettergevoelige bestandsnamen te hebben.

[Reactie gewijzigd door v0LrAtH op 24 juli 2024 23:29]

[RoestVrijStaal]

Dan zijn die versioning systemen enkel in een Windows-omgeving geïmplementeerd, wat hilarisch slecht is.

[Werelds]

Heh?

Ik denk dat v0lrAtH hier op iets anders doelt dat niet volledig op het eerste comment slaat.

Zowel NTFS als HFS+ zijn in principe* case-insensitive en case-preserving (FAT32 overigens ook). Wat dat betekent is dat je een bestand als "Whatever.txt" kunt opslaan, maar aan kunt spreken (via Command Prompt/Terminal) als "whatever.txt". In Explorer/Finder zul je het bestand als "Whatever.txt" zien staan, met de correcte case dus.

Waar v0lrAtH *denk ik* op doelt is dat als je in OS X een bestand hernoemt en daarbij alleen hoofdletters verandert (en het maakt niet of je dat via Terminal of Finder doet) dat niet daadwerkelijk opgeslagen wordt in de bestandstabel, waar dat bij NTFS wel het geval is. Dus doe jij "mv Whatever.txt whatever.txt" wordt dit als een "noop" (no operation) gezien er veranderd er in feite helemaal niets - het bestand wordt niet hernoemd en staat gewoon in de bestandstabel als "Whatever.txt". Het gevolg is dat de meeste VCS dit niet oppikken. Met NTFS wordt dat wel gewoon opgeslagen en zal je VCS die verandering dus ook op kunnen pikken.

Ik weet niet of dit nu aan OS X of aan HFS+ ligt, maar dit is inderdaad hoogst irritant. De eerste keer dat wij hier tegen aan liepen duurde het ook een hele tijd eer we door hadden dat OS X/HFS+ hier zo idioot slecht mee om gaan. Ik hoop dat ze dit nu dus wel goed doen. Door "git mv" te gebruiken kun je er bijvoorbeeld wel omheen werken, maar netjes is anders.

Screenshot van dit verhaal: http://cl.ly/3U0K0y1X1c3f


* Je kunt een schijf wel HFS+ case-sensitive formatteren, maar dan zullen sommige applicaties moeite hebben (slechte applicaties naar mijn mening, maar dat is een ander verhaal).

[Reactie gewijzigd door Werelds op 24 juli 2024 23:29]

[PPie]

OS X met HFS+ (niet case-sensitive) is 'case insensitive, case keeping'. Je kunt dus zeker wel een file van naam veranderen met alleen verschillen in hoofdletters en dit wordt zeker wel opgeslagen en het is zeker geen no-op.
Het probleem zit hem er echter in dat de applicaties die bovenop HFS+ draaien een file kunnen benaderen via een pad dat niet precies de hoofdletters volgt (dus 'case insensitive'). Dus 'whatever.txt' en 'Whatever.txt' worden als dezelfde file gezien. Dit kan dus een probleem zijn als programmeurs onderdelen van hun app verkeerd benaderen. Ik weet dat dit ooit een probleem was met de Adobe suite.

[WhatsappHack]

Dat is het nog steeds.
Sterker nog, als je HFS+ gebruikt met case-sensitivity, dan weigert Adobe ook maar te installeren. Diep triest.

Case-sensitive filesystems zijn zo verschrikkelijk veel relaxter dan die insensitive troep.

[wiert.tweakers]

Daarom doe ik altijd op elk OS `git mv Whatever.txt whatever.txt`

Windows heeft er overigens ook een handje van dat je soms niet `Whatever.txt` naar `whatever.txt` kunt renamen.

Verder ben ik het met je eens over applicaties die moeite hebben met een case sensitive file system.

We leven in een wereld waar steeds meer dingen met elkaar samenwerken en uitwisselbaar zijn dus software moet er maar eens tegen kunnen dat een filesysteem case-sensitive is.

[v0LrAtH]

Niet noodzakelijk waar. Als een versioning systeem een "case-wijziging" ziet en probeert naar je lokale Windows systeem te pushen, dan lukt het hem niet om dit correct door te voeren. Dit levert zowel bij Subversion als Mercurial problemen op.

Zonet nog gehad in Mercurial: Exception during merge abort: case-folding collision

[MrMonkE]

Ik heb het ook wel eens met een archive die van een mac komt. Dan zit er ReadMe en README in en vraagt hij bij de 2e het te overschrijven.

[Themperror]

In het geval van windows kan dit tegenwoordig wel sinds 10 (of 8 al? nooit gebruikt)
Als je in windows 7 verkenner renamed:
henk.txt -> Henk.txt = henk.txt (verandert niks)
Op windows 10 verkenner
henk.txt -> Henk.txt = Henk.txt (hoofdletter verschil ziet ie)

op 7 moest je dus eerst de naam zelf veranderen en daarna naar het "gefixte" naam met hoofdletter bijvoorbeeld
henk.txt -> enk.txt -> Henk.txt = Henk.txt

Dus met de laatste versie van windows zou je daar dan geen problemen mee krijgen (tenzij je 2 aparte files dus probeert dezelfde naam te geven met alleen hoofdletter verschil) want files ziet windows zelf wel gewoon allemaal zonder hoofdletters om het zo te noemen.

[Themperror]

RoestVrijStaal hier heeft wel gelijk, zover ik weet is "Linux" met Ext4 ook gewoon hoofdletter gevoelig..

Daarnaast is het bestandssysteem voor PS4 en XboxOne, 3DS (en daarbij waarschijnlijk Wii en WiiU) ook Hoofdletter gevoelig

Als je nu nog programma's maakt die daar geen rekening mee houden (En dan sluit ik windows-only (NTFS/FAT-only?) programma's uit) is het gewoon slecht.

[Reactie gewijzigd door Themperror op 24 juli 2024 23:29]

[sfranken]

zover ik weet is "Linux" met Ext4 ook gewoon hoofdletter gevoelig..

Jep:

$ touch a A
$ echo 'dit is a' > a
$ echo 'dit is b' > A

$ cat a => "dit is a"
$ cat A => "dit is b"

Alsin, a en A zijn twee verschillende files.

[MrMonkE]

ntfs kan gewoon hoofdlettergevoelig zijn.
Kan al sinds vorige eeuw.

[Blokker_1999]

Dat klopt, NTFS is een POSIX compliant bestandssysteem en is daardoor hoofdlettergevoelig. Het "probleem" is dat veel software dat niet is en bijv. zelfs je Windows verkenner je niet zal toestaan om gebruik te maken van deze functionaliteit.

[MrMonkE]

Ook niet als je dit inschakelt in je file systeem?
Want ik meen me te herinneren dat het standaard uit staat.

Het lijkt mij dat windows zelf hier wel in voorziet.

Zelf ben ik voorstander van een case insensitive file systeem.
Het lijkt me minder gevoelig voor human error.

[Blokker_1999]

Als Linux gebruiker ben ik dan weer net voorstander van case sensitive bestandssystemen. Het is op zovele niveaus gewoon eenvoudiger om een vergelijking te doen. Want anders ga je zeggen dat a gelijk is aan A en dat is niet zo.

[MrMonkE]

Losse spaties is ook niet hetzelfde als tabs.
Voorzichtig op de trap

Maar ja, potato potAto.
Gelukkig kunnen we kiezen


(refrentie/context: https://www.youtube.com/watch?v=SsoOG6ZeyUI )

[Reactie gewijzigd door MrMonkE op 24 juli 2024 23:29]

[Verwijderd]

Exact mijn gedachte. Ik heb juist een sterke voorkeur voor hoofdletter gevoelige bestandsnamen.

[Nas T]

Ik ook, maar het gaat er denk ik om dat het niet ongedaan te maken is:

Perhaps most importantly, the file system currently is case-sensitive, and this cannot be disabled. HFS+ breaks with most Unix-y file systems in that it can be configured to not use case sensitivity; in fact, running OS X—ahem, macOS, sorry—with case-sensitive HFS+ can lead to its own problems.

[CAPSLOCK2000]

Ik ook, maar het gaat er denk ik om dat het niet ongedaan te maken is:

Ze voeren nu een nieuwe filesysteem in, dat lijkt me een heel geschikt moment om zo'n regel te veranderen.

[Nas T]

Misschien is mijn uitleg wat onhandig. Het leidt waarschijnlijk tot incompatibiliteit omdat het minder mogelijkheden biedt dan andere bestandssystemen. En dat wil je waarschijnlijk niet...

[svenk91]

Da autocorrect vaak ergens een hoofdletter neer plempt. Linkje delen, vergeten auto-capitalisation uit te zetten, opeens bestand not found

[Aikon]

Dat betekend dat example.exe en Example.exe (etc.) twee verschillende bestanden zijn. Dat kan voor verwarring zorgen.

[CAPSLOCK2000]

Ik vind het minstens zo verwarrend dat er twee verschillende namen voor hetzelfde bestand zijn. Dat is echter geen goed argument meer. We hebben ook geen filesystemen die geen onderscheid maken tussen de 'i' de 'l' en de '1' of de '0' en de 'o' om verwarring te voorkomen.

[Jeanpaul145]

Als dat soort verwarring nu nog niet is voorgekomen na meer dan 30 jaar home computing dan zal het ook niet meer gebeuren denk ik

[TommyboyNL]

Case insensitivity zorgt ervoor dat mensen onzorvuldig gaan programmeren, en nog veel meer fouten maken. Lekker case sensitivity behouden, dan blijven de programmeurs ook scherper.

[Zer0]

Stop die case sensitivity dan lekker in de programmeertaal, dan blijven de programmeurs scherp en heb ik er als gebruiker geen last van

[skatebiker]

Oftewel "waarom makkelijk als het moeilijk kan", wat dat is het eigenlijk.

Ik zie totaal het nut niet van case sensitivity. Zeker als je met CamelCase ProGrammEert dan kun je snel fouTen maKen, want waar plaats je de HoofdLetter ?
Als je case insensitive programmeert dan leidt camel case ook tot minder verwarring dan is immers variableName == Variablename.

[supersnathan94]

VariabeleNaam mag echter nooit gelijk staan aan Variabelenaam. Iedere programmeertaal die ik heb gebruikt is case sensitive.

[watercoolertje]

Hij zegt niet dat mensen het niet kunnen lezen, maar niet hoeven te beseffen dat het 2 verschillende apps (kunnen) zijn. https://tweakers.net is ook hetzelfde als https://TWEAKERS.NET

[Wim-Bart]

Http://site.nl/index.html is op een linux server toch iets anders dan http://site.nl/INDEX.html

[watercoolertje]

Niemand ontkent dat het op linux geen verschil uit maakt (en dat doet er ook niet echt toe), maar dat wil niet zeggen dat iedereen het gewend is, en het vanzelfsprekend is voor iedereen...

[Reactie gewijzigd door watercoolertje op 24 juli 2024 23:29]

[RoestVrijStaal]

Niets, dat daar een minpunt van wordt gemaakt is enkel de erfenis van dat Microsoft een quick'n'dirty OS had gekocht om daarop door te ontwikkelen.

[Reactie gewijzigd door RoestVrijStaal op 24 juli 2024 23:29]

[hottestbrain]

Dos heeft er echt al ontzettend lang niets meer mee te maken...

[MaxxMark]

Volgens mij heeft nooit iemand OSX met HFS+ met case-sensitieve FS gebruikt. Ik heb het één keer gedaan met exact dezelfde gedachte; "Wat is er mis mee?"

Vervolgens kom je er achter dat 90% van de applicaties er van uit gaat dat het OS case-INsensitive is (let wel dat wat "Werelds" zei ook van toepassing is; case-sensitive is niet gelijk aan case-perserving).

Een voorbeeld is Steam; deze gaat uit van case-insensitive en geeft er goed de brui aan als je het probeert te starten op een case-sensitive filesystem. Wat je dan moet doen is een losse image (dmg) maken die case-insensitive is, en op die virtuele parttime steam installeren. Zeer omslachtig.

Ik heb het een kleine 2 jaar geleden gedaan en heb na een paar manden mn mac herinstalled met case-insensitive filesystem omdat heel veel applicaties er niet goed mee om konden gaan.

[joint_me]

Je kan een HFS+ nu ook instellen dat het hoofdletter gevoelig is, maar dan werkt Photoshop niet meer en andere software.

Dit was in ieder geval enkele jaren geleden zo, daarna heb ik nooit meer de neiging gehad om het nogmaals te proberen.

[Verwijderd]

Iemand al zo moedig geweest om het te proberen?

apfs_hfs_convert /dev/disk0

[beschoenen]

Ik vindt het space sharing wel een leuk concept.
Vooral voor mensen die dual booten, gewoon partities kunnen maken op zelfde fysieke ruimte van een schijf en samen nemen ze alle ruimte weg. Dat hoef je te gokken op hoeveel ruimte je nodig hebt als je vanuit macOS bijvoorbeeld een Windows partitie wilt aanmaken.

[Q-collective]

An open source implementation is not available at this time. Apple plans to document and publish the APFS volume format when Apple File System is released in 2017.

Bron.

Zou APFS beschikbaar komen onder de APSL, een licentie die door de FSF wordt aangemerkt als vrije software licentie, dan zou dit heel makkelijk de huidige "next gen" bestandssystemen BTRFS en ZFS volledig kunnen wegvagen: BTRFS zit nog zwaar in ontwikkeling en maar een enkeling die het waagt op productiesystemen te zetten waar data van belang is (SUSE comes to mind) en ZFS heeft langlopende licentieproblemen met de GPL, waardoor implementatie in de Linux kernel bijzonder moeilijk is.

Zou APFS dan eindelijk het echte universele bestandssysteem kunnen worden?

[aileron]

Ik zie Apple eerder het zelfde doen als MS heeft gedaan met exFAT:

Microsoft has not officially released the complete exFAT file system specification and a restrictive license from Microsoft is required in order to make and distribute exFAT implementations. Microsoft also asserts software patents on exFAT which make it difficult to re-implement its functionality in a compatible way without violating a large percentage of them.

Als Apple dus zegt "Apple plans to document and publish the APFS volume format" dan hoeft dat niet te betekenen dat de computer industrie een open standaard er bij heeft en iedereen er uiteindelijk beter van zal worden. Eerder het omgekeerde als je hun trackrecord er bij pakt.

edit: source van mijn quote

[Reactie gewijzigd door aileron op 24 juli 2024 23:29]

[Verwijderd]

Kijk, innnovatie- een goede zaak. Als het maar wel een echte verbetering is, niet alles wat Apple bedenkt en implementeert, is per se vooruitgang (helaas.)

Geoptimaliseerd voor encryptie, daar ging mijn hart sneller van kloppen- want mij is nog steeds niet helemaal duidelijk, of disk-encryption (FileVault) extra 'wear&tear' met zich meebrengt voor je ssd.
Wat staat er echter onderaan in het artikel: "Er zijn nog wel enkele struikelblokken voor het gebruik. Zo kan APFS nog niet voor opstartschijven gebruikt worden, zijn bestandsnamen nog case-sensitive, worden back-ups van Time Machine nog niet ondersteund, kunnen volumes nog niet met FileVault versleuteld worden en kan het bestandssysteem nog niet overweg met Fusion Drives van Apple-computers."

Ofwel: nog werk aan de winkel, want dat zijn juist de dingen die je wilt, lijkt mij.

[Jerie]

Apple gaat aes-xts of aes-cbc gebruiken, afhankelijk van de hardware.

Jammer. AES-XTS is prima, AES-CBC heb je niets aan. Dat is snake oil. Want je data leaked.

[Verwijderd]

FileVault gebruikt (sinds versie 2 uit 2012) standaard XTS, dus ik neem aan dat dat voor APFS ook geld, tenzij het echt niet anders kan.

[latka]

Je bedoelt dat je gericht data kan veranderen in de encrypted text die dan terugkomt na decryptie in de plaintext? Dat is wat ander dan data lekken en snakeoil. Https is ook meestal cbc en daar is niks mis mee. Verklaart u nader ipv fud strooien.

[latka]

Als je de bronnen die je opgeeft leest zijn dat de padding Oracle en wat zaken rondom veilig gebruiken van IV. Geen groot gapend gat in aes-cbc vs xts zolang je het goed toepast. De reden dat ik zo reageer is omdat er nogal wat cbc in gebruik is (vpn, tls) en een groot gapend gat zou vervelend zijn. Xts helpt dan ook voornamelijk tegen tampering van encrypted data. Beter is het naast crypto een hmac toe te voegen om daartegen te beschermen.

[Jerie]

Je gaat er van uit dat VPN veilig is, ik niet.

Watermark aanval is bij beide van toepassing. Bij XTS niet.

Gebruik je FDE dan moet je XTS gebruiken (in de tussentijd is LRW ook nog een tijdje een alternatief geweest). Dat is al een kleine 10 jaar bekend.

[Verwijderd]

Verklaar je nader, want je zegt niets. Bovendien, wat is er mis met een nieuw bestandsysteem? Als je je eigen FS kunt ontwikkelen, ben je mijns inziens geen amateur. Ga er maar vanuit dat de huidige opties onderzocht zijn, en dat er een hele goede reden is om dit systeem te ontwikkelen. Zeker aangezien het plan is om het opensource te maken en dus niet proprietary.

Dus als je even de "niet kort-door-de-bocht" vertaling wilt geven met argumenten, dan hebben we iets om over te babbelen.

[Blokker_1999]

Waar hij op doelt is: waarom een nieuw, eigen, bestandssysteem ontwikkellen wanneer er zoveel goede open source bestandssystemen zijn waar men eventueel ook aan zou kunnen bijdragen?

[Maurits van Baerle]

Ik weet er maar één die een serieuze optie zou kunnen worden en dat is BTRFS. En volgens mij mist die nog teveel functies om door Apple op korte termijn geimplementeerd te kunnen worden. ZFS gaat het helaas niet worden om licentie technische reden.

[Rafe]

Btrfs is GPL-gelicenseerd en met name versie 3 houdt Apple klaarblijkelijk niet zo van, bijv. Samba en GCC zijn uit OS X gehaald door de jaren heen.

ZFS was in de Sun-tijd beloofd voor Snow Leopard Server maar dat is in een stille dood gestorven. Inmiddels gaat Oracle er over maar kennelijk zag Apple zich toch genoodzaakt vanaf scratch te beginnen. Gezien de vuistregel 'buy/use before make' zullen ze daar wel goed over nagedacht hebben.

[Reactie gewijzigd door Rafe op 24 juli 2024 23:29]

[Maurits van Baerle]

GPL an sich is voor Apple geen probleem, ze brengen zelf ook dingen uit onder de GPL en er zit redelijk wat GPL code in macOS.

GPL 3 kan inderdaad niet, die verbied het gebruik in implementaties zoals die van Apple.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 23:29]

[Verwijderd]

Nee, daar doelt hij niet op. Hij zegt dat Apple in zijn ogen moeite heeft met het implementeren van andermans specificaties "Omdat wij nogal moeite hebben andermans specs te interpreteren, maken wij ons eigen wiel." .

Het is een niet gefundeerde, ongeïnformeerde uitspraak.

[pBook]

Je reactie is nogal kort door de bocht. Apple had ooit een ZFS implementatie klaar maar er zijn vele andere redenen waarom dit op de plank is blijven liggen, interpretatie is daar waarschijnlijk niet één van. Er komt behoorlijk wat kijken bij een nieuw filesystem, vandaar ook de nodige restricties op de beta versie van APFS.

[sfranken]

Nee hoor. Als je de specs leest en je pakt die van ZFS (of btrfs) erbij dan krijg je een zeer sterk deja-vu gevoel...