Mike Bombich : prudence avec APFS dans macOS High Sierra

Florian Innocente |

macOS High Sierra apporte un tout nouveau système de fichiers et le peu d'informations données par Apple à son sujet alarme Mike Bombich, l'éditeur du vénérable utilitaire Carbon Copy Cloner.

Chaque révision majeure de macOS est une opportunité pour ces logiciels qui offrent un filet de sécurité en cas d'échec lors de la grande mise à jour. Sauf que cette année est plus spéciale que les précédentes, High Sierra touche à l'une des fondations de macOS. Il remplace HFS+, le moteur qui s'occupe de gérer le moindre fichier de votre Mac (écriture, copie, duplication, suppression…), par une version toute neuve et moderne : APFS. Ce dernier est déjà utilisé par les iPhone, les iPad, les iPod touch et les Apple TV depuis iOS 10.3 et tvOS 10.2 — la transition s'est d'ailleurs formidablement déroulée.

Carbon Copy Cloner

Carbon Copy Cloner ayant comme fonction de réaliser des sauvegardes et clones du contenu d'un disque dur ou d'un SSD, le détail du fonctionnement d'APFS intéresse ses développeurs au premier chef.

Dans un billet publié il y a quelques jours, Mike Bombich se désole de la maigreur de la documentation offerte par Apple. 10 petites pages face aux 59 pages d'HFS+. À la décharge d'Apple, HFS+ date de 1998, il s'appuyait sur HFS et il n'est pas surprenant qu'avec une telle ancienneté il soit parfaitement documenté.

Cependant, à environ 2 ou 3 mois de la sortie de High Sierra, Bombich s'inquiète que certaines fonctions clefs, comme les "snapshots" ou "instantanés" (une réinterprétation de la fonction Time Machine) soient survolées à grande vitesse avec, pour ainsi dire, zéro détail technique exploitable.

Le manque de documentation n'est pas un petit problème. Les questions de base restent sans réponse, telles que "Comment puis-je déterminer l'espace qu'utilise un instantané en particulier ?" Et "Comment puis-je déterminer si 'le fichier Y' est un clone du 'fichier X'?" En voici une bonne : comment puis-je déterminer de façon sûre l'espace qu'un dossier en particulier utilise vraiment ?

Toujours pour cette fonction de "snapshots" il s'inquiète de voir Apple ne fournir aucune API aux éditeurs tiers. Pour Bombich, cette partie d'APFS n'est pas encore prête et pourtant le jour de sa sortie générale approche à grands pas. Il dresse un parallèle avec le nouveau composant réseau Discoveryd qu'Apple avait installé dans Yosemite avant de faire machine arrière devant les instabilités créées.

La comparaison est peut-être un peu forte en l'état puisque High Sierra est toujours en bêta et qu'il reste quelques semaines pour qu'Apple accède à la demande de tels éditeurs. Bombich redoute néanmoins qu'Apple n'aille un peu vite en besogne en livrant dès cet automne ce gestionnaire de fichiers aux millions d'utilisateurs de Mac. Il conseille à ceux-ci de ne pas se précipiter sur APFS et d'attendre quelque temps à distance raisonnable.

L'activation d'APFS lors de l'installation du système est optionnelle, mais la case pour le faire est cochée par défaut — du moins dans les bêtas actuelles. On peut toujours différer cette migration qui est réalisable ensuite avec Utilitaire de disques. Cela se fait sans avoir à effacer les fichiers présents. De même que l'on peut ramener un volume d'APFS vers HFS+ mais là, c'est au prix d'un reformatage préalable.

Cliquer pour agrandir

avatar r e m y | 

@doctomac

Il est certain que cette transition vers APFS a été annoncée avec une beaucoup plus grande anticipation que lors du passage de HFS à HFS+ (ceux qui ont vécu cette transition en ont encore des sueurs froides...)

Il n'en reste pas moins qu'un an apres, la doc mise à disposition des développeurs est pour le moins succincte et certains paragraphes de cette doc "technique" font plus penser à une plaquette commerciale.
Comme le relève Mike Bombich, rien n'est rendu public par exemple sur le fonctionnement des snapshots.

Pour l'utilisateur lambda (qui n'a pas accès aux ressources développeurs), les modifications apportées et nouveaux paramètres utilisables avec diskutil (accessible via le Terminal) ne sont pas encore documentés via un "man diskutil"

avatar agapimou1 | 

@remy

On a compris que ce n'était pas encore documenté. Tu as dû l'écrire une bonne dizaine de fois maintenant ! Ca on peut dire que tu rabâches les choses un certain nombre de fois...

avatar tchit | 

Je trouve ça assez incroyable de déployer un tout nouveau système de fichiers sur des millions de machines qui vont faire la mise à jour, sans l'avoir bêta testé des années au préalable.

avatar r e m y | 

@tchit

Il a été testé en interne depuis au moins 3 ans d'après ce qu'Apple a indiqué lors des WWDC 2016 et 2017.
Mais il n'y a maintenant qu'un bêta test public qui peut révéler des situations spécifiques impossibles à anticiper via les tests internes.

avatar tchit | 

@r e m y

Testé en interne 3 ans, ça signifie qu'il existe depuis 6 ans ?
Dans tous les cas, une beta c'est quand des utilisateurs extérieurs peuvent tester et pour le moment c'est encore un système extrêmement jeune sans avancées très utiles comparé au HFS+, donc qui ne devrait être installé que par les bidouilleurs...

avatar fte | 

@tchit

Microsoft teste ReFS depuis plus de 5 ans et ne le recommande toujours que pour quelques cas bien précis, malgré ses qualités indéniables par rapport à NTFS.

Ça me semble beaucoup plus sain et raisonné. Quoique frustrant.

Et ils ont (je pense volontairement) bridé certains aspects pour que son usage reste une décision réfléchie.

Pourtant l’ambition est de remplacer NTFS partout à terme, mais ils planifient l’operation sur 10 ans.

avatar tchit | 

@fte

L'autre truc frustrant c'est quand même qu'en 2017 il faille installer des utilitaires pour rendre OS X compatible avec NTFS et Windows avec HFS+... mais apparemment c'est pas près de changer.

avatar r e m y | 

@tchit

C'est bien le probleme des systèmes et formats propriétaires...
Avec APFS on va même se trouver avec un format qui ne sera reconnu que par des Macs récents sous HighSierra.
Je n'ai pas encore fait le test (c'est ton commentaire qui m'y fait penser), mais je ne pense pas qu'un Mac n'ayant pas installé HighSierra sache lire (et encore moins écrire) un disque formatté APFS.
À moins qu'Apple ait prévu la retrocompatibilite, au moins en lecture, avec les versions précédentes de macOS.

avatar BeePotato | 

@ r e m y : « C'est bien le probleme des systèmes et formats propriétaires... »

Mouais… C’est tout de même bien plus lié à la volonté d’un éditeur d’OS de faire un effort en ce sens qu’à la nature « propriétaire » ou non des FS concernés. On a, par exemple, encore moins de support par défaut dans Mac OS des divers systèmes de fichiers opensource que de NTFS.

avatar r e m y | 

@BeePotato

C'est vrai egalement... disons qu'avec les formats propriétaires, ils ont l'excuse de l'absence de publication des spécifications pour ne pas l'implementer.

avatar BeePotato | 

@ r e m y : « disons qu'avec les formats propriétaires, ils ont l'excuse de l'absence de publication des spécifications pour ne pas l’implementer. »

Ils ont cette excuse avec les formats dont les spécifications n’ont pas été publiées — car rappelons qu’un format peut être « propriétaire » tout en étant totalement documenté.

avatar fte | 

La seule question à se poser à ce stade est la suivante : avez-vous BESOIN d’une fonctionnalité que propose APFS et que ne propose pas HFS+/CoreStorage ?

Non : restez sur la solution stable.

Oui : une image disque ou une clé USB ou un drive externe dédié est sauf situation rarissime absolument suffisant.

avatar r e m y | 

@fte

APFS est extrêmement prometteur.
La façon dont il gère les partitions d'un disque par exemple, permet enfin de ne plus se poser la question de la bonne taille de celles-ci lors du partitionnement.
Un TimeMachine réécrit pour tirer parti d'APFS devrait être génial (sous réserve qu'Apple ait prévu de le réécrire ou de donner aux développeurs les moyens de le faire)
....
Mais à ce stade, je ne pense pas qu'il y ait urgence à se précipiter pour l'adopter sauf des machines de tests

avatar fte | 

@r e m y

J’ai redimensionné des dizaines de partitions HFS+, je ne saurais dire combien, sans prise de tête aucune.

Et ce seul point ne saurait justifier de risquer les données, en particulier sur les millions de machines qui n’utilisent qu’une seule partition anyway.

Les snapshots sont très intéressants en effet, mais les bénéfices pour les logiciels de backups sont minimes. C’est plus l’aspect de déduplication du disque de destination qui est intéressant, certains logiciels de backups utilisent leur propre format d’archive pour ce faire.

Ce qui est véritablement intéressant avec APFS : copy on write. Idéalement avec le catalogue, ce dont je ne suis pas sûr. A vérifier.

avatar h-de-pierre | 

J'ai installé la dernière beta sur une partition vierge. Rien ne m'a été proposé pour passer sur APFS.

avatar r e m y | 

@h-de-pierre

Soit tu utilises un disque dur traditionnel (à plateaux), soit un FusionDrive 3To comportant une partition BootCamp, soit un disque externe. (Il me semble que ce sont les 3 cas dans lesquels, bien que la conversion soit possible via Utilitaire Disques, Apple ne le propose pas spontanément)

avatar h-de-pierre | 

Fusion Drive de 3 To. pas de BootCamp.

J'ai formaté en APFS avant l'installation, en bootant sur la partition de récupération. Au moment de l'installation, macOSHS a refusé de continuer. Il lui faut une partition HFS+

avatar r e m y | 

Ce n'est pas cohérent avec ce que tu disais au départ.. ce n'est pas que le passage à APFS ne t'a pas été proposé, mais que tu as fait cette conversion avant même de lancer l'installation d'HighSierra!

Il faudrait reformatter ton Fusion Drive en HFS+ et réinstaller une sauvegarde précédente (le reformattage APFS vers HFS effaçant les données du disque).

Ensuite seulement tu pourras installer la beta de HighSierra et éventuellement valider la conversion APFS

avatar agapimou1 | 

@remy

A dis donc ! tu es à ton affaire avec cette histoire de APFS... Tu te la pètes un peu...
Mais, tu ne fais pas parti des équipes d'Apple ! Tu ne sais absolument pas comment est architecturé leur APFS, ni comment il fonctionne ... Tu devrais cesser de prodiguer tes leçons...

avatar Bigdidou | 

@agapimou1

« Tu devrais cesser de prodiguer tes leçons »

Et toi de donner des conseils imbéciles.
Et viens surtout pas dans les forums quand tes données auront disparu : ce serait quand même dommage de devoir demander conseil à « des types qui se la pète ».
Si tu peux pas comprendre le danger qu’il y a à utiliser un système de fichiers pas finalisé, c’est ton problème, mais ne mets pas les autres dans la merde.

« Certains essaient même de provoquer les insultes »

Oui, toi, par exemple. Qui t’a d’emblée agressé ici ?
Personne.
Toi, par contre...
T’es défoncé, ou quoi ?

avatar h-de-pierre | 

@ r e m y

Ok Merci. Je vais tester ça !

avatar agapimou1 | 

@h-de-pierre

J'ai eu la même chose en installant High Sierra, pas de proposition de conversion vers APFS. J'ai un Fusion Drive 1 To. Il faut que tu redémarres ta machine en appuyant sur CMD + R. Ensuite, tu choisis l'utilitaire de disque et tu vas dans le menu Edition. Tu y verras "Conversion vers APFS..."

Lorsque tu auras lancé la conversion ça dure assez longtemps presque une heure, il faut être patient et attendre la fin du processus de conversion.

Voilà , bonne chance. Moi je suis passé sous APFS et j'en suis très content aucun problème à signaler.

avatar fte | 

@h-de-pierre

C’est ce que me rapportait un collègue aussi. Je n’ai pas vérifié.

Mais je ne serais pas étonné que ce soit lié au bug de normalisation UNICODE, c’est assez clairement un bug critique bloquant.

Je hurlerais de rire si MacOS HS était livré à l’automne sans le support d’APFS. Et je n’en serais pas tellement surpris.

avatar r e m y | 

@fte

Apple a été clair sur le sujet. L'implementation d'Unicode tel qu'elle l'est avec APFS est un choix délibéré et en aucun cas un bug.

avatar fte | 

@r e m y

Qu’il y ait normalisation c’est une chose (compréhensible pour de l’électroménager, vu que c’est ce que fabrique Apple maintenant). Que la normalisation pue du cul en est une autre.

avatar r e m y | 

@fte

? ? ?

avatar h-de-pierre | 

?

avatar Bigdidou | 

@fte

Félicitations. Le truc l’air de rien entre parenthèse, mais 1000 points de plus d’un coup dans son karma trollesque, c’est pas tout le monde qui peut faire ça ;)

Sinon, oui, ça me parait difficile de migrer vers un système de fichiers si la base de la base, des logiciels de clonage et de sauvegarde incrémentielle, n’est pas prête.

On ne peut que remercier ce développeur de son alerte qui amène la prudence.

avatar fte | 

@Bigdidou

"Félicitations."

Merci ?

"Le truc l’air de rien entre parenthèse, mais 1000 points de plus d’un coup dans son karma trollesque, c’est pas tout le monde qui peut faire ça ;)"

D’un autre côté la grande nouvelle de l’été, ce sont de nouveaux emoji cette année.

Je force le trait, certes, mais je n’ai pas complètement tord non plus.

avatar Bigdidou | 

@fte

« Je force le trait, certes, mais je n’ai pas complètement tord non plus. »

Non, et j’ai mis un ;) D’ailleurs j’ai trouvé la réponse qu’on (beepatato ou feefee) t’a faite plutot fine.

Sinon, pas de toi, non, pitié. Je comprends les fautes, j’en fais aussi , t’en fais moins que moi, mais celle là, sa récurrence m’éneeeerve, c’est fou...;)

avatar fte | 

@Bigdidou

"m’éneeeerve"

Désolé ?

avatar BeePotato | 

@ fte : « Qu’il y ait normalisation c’est une chose (compréhensible pour de l’électroménager, vu que c’est ce que fabrique Apple maintenant). »

Pour ma part, je préfère cet « électroménager » et sa normalisation à un Linux et son « tout ça c’est qu’un paquet d’octets » qui permet de se retrouver avec deux fichiers différents ayant le même nom. Mais bon, quand on dérive d’un système où le nom n’est même pas considéré comme un attribut du fichier, on ne peut pas s’attendre à un gros effort sur ce point… ;-)

« Que la normalisation pue du cul en est une autre. »

Histoire d’éclairer ma lanterne : que lui reproches-tu exactement, à la gestion de l’Unicode dans les noms de fichiers en APFS, qui fasse qu’elle pue à ce point-là à tes yeux (si j’ose dire) ?

Attention : je parle bien de la version actuelle (et probablement finale), pas des errements qu’il y a eu dans ce domaine les mois précédents (et qui laissaient craindre qu’on allait descendre à niveau linuxien, voire pire, dans ce domaine).
La préservation de la normalisation des noms est un gain (par rapport à HFS+) lors des échanges avec les autres OS, et l’insensibilité à la normalisation permet d’éviter que ce gain ne se transforme en cauchemar pour les utilisateurs et les développeurs. Ça ne me semble pas trop mal, comme approche (mais je trouve ahurissant que cette approche n’ait pas été celle retenue dès le début — bien que j’ai appris à ne plus trop m’étonner de l’inculture de bien trop de développeurs au sujet de l’encodage des chaînesde caractères).

avatar fte | 

@BeePotato

Va lire les rapports de bugs sur la normalisation des caractères accentués d’APFS.

Selon l’API et selon l’encodage utilisé tu peux créer des fichiers ayant le même nom dans le Finder mais à la normalisation différente. Sauf que l’un est inaccessible tant que l’autre est dans le même dossier. Par exemple. Il y a d’autres effets de bord.

Dit autrement la normalisation est niveau API et non niveau FS. Ça pue absolument et totalement.

Sauf erreur, pas de normalisation sur iOS. Donc pas de problème.

avatar BeePotato | 

@ fte : « Va lire les rapports de bugs sur la normalisation des caractères accentués d’APFS.
Selon l’API et selon l’encodage utilisé tu peux créer des fichiers ayant le même nom dans le Finder mais à la normalisation différente. Sauf que l’un est inaccessible tant que l’autre est dans le même dossier. Par exemple. Il y a d’autres effets de bord.
Dit autrement la normalisation est niveau API et non niveau FS. Ça pue absolument et totalement. »

Je les ai lus.
Maintenant, relis ce que j’ai écrit : je parle bien de la version actuelle (et probablement finale), pas des errements qu’il y a eu dans ce domaine les mois précédents.

Les problèmes que tu cites, ce sont justement les errements auxquels je faisais allusion. Mais ils sont réglés par l’approche qui a finalement été retenue pour gérer les conflits de formes Unicode, qui empêche de créer deux fichiers aux noms identiques à la forme près.

Cette approche n’est pas la même que celle utilisée dans HFS+, où les noms étaient tous normalisés de la même façon avant d’être enregistrés dans le FS. Avec APFS, ils seront conservés tels que fournis par les clients du FS, mais les comparaisons de noms seront insensibles à la normalisation choisie pour tel ou tel caractère (ce qui revient à dire qu’ils sont convertis à la même normalisation avant d’être comparés, quoi).
C’est cette seconde partie qui manquait jusque là et qui générait les problèmes que tu as cités.

Sauf que maintenant, c’est du passé.

Avec l’approche retenue, le seul type de possible effet de bord qu’il reste, c’est au niveau de la comparaison de noms de fichiers au sein des applications, mais là c’est aux développeurs d’applications de faire des comparaisons de chaînes correctes.

« Sauf erreur, pas de normalisation sur iOS. Donc pas de problème. »

Si, si, il y a bien eu des problèmes sur iOS, avec quelques développeurs s’arrachant les cheveux. Et c’est normal, puisque c’est bien l’absence de normalisation qui générait ces problèmes.

avatar fte | 

@BeePotato

Le fix est-il déployé dans la b3 ? Il ne l’était pas dans la b2.

avatar BeePotato | 

@ fte : « Le fix est-il déployé dans la b3 ? Il ne l’était pas dans la b2. »

Je n’en ai aucune idée. Je t’avoue que je ne me suis pas penché sur la question, n’étant pas beta-testeur. Tout ce qui m’importe est de savoir ce qu’il y aura dans la version finale, et je suis rassuré sur ce point depuis que cette modification a été annoncée.

avatar fte | 

@BeePotato

Okay, lu.

Mvouais.

C’est possiblement une solution, en supposant que le test d’unicité/existence dans un dossier soit correctement implémenté au niveau du fs, et que donc une création de fichier ne puisse résulter en doublons selon l’API attaquée. A voir à la conversion quels pourraient être les effets indésirables...

Ce n’est absolument pas clair. Tu as l’air de penser que ça résout tous les problèmes, mais mon détecteur à emmerdes me hurle dessus à plein volume. Ce n’est en tout cas pas ce que je qualifierais d’élégant.

La documentation est inexistante si on est gentil, fucking abysmal si on est honnête.

Je crois que la prudence la plus absolue est nécessaire : se tenir le plus loin possible d’APFS si on n’a pas une raison impérieuse et incontournable de l’utiliser. Si on veut se faire peur, un rollercoaster est bien plus sympa.

(Disclaimer: ça fait quelques années que ma confiance en Apple voisine le 0 en matière de fiabilité. J’ai des raisons pour le justifier. Ce merdier autour d’APFS à un trimestre de la sortie officielle, avec des beta publiques dispo, ne va pas remonter le score.)

avatar BeePotato | 

@ fte : « C’est possiblement une solution »

Pas juste « possiblement ». C’est une solution, point.

« en supposant que le test d’unicité/existence dans un dossier soit correctement implémenté au niveau du fs »

Ah ben oui, pour supposer que le FS fonctionne correctement, on doit supposer qu’il est implémenté correctement. :-)

« et que donc une création de fichier ne puisse résulter en doublons selon l’API attaquée. »

D’après ce qui est dit dans le documentation, c’est bien le cas.

« A voir à la conversion quels pourraient être les effets indésirables... »

D’après le fonctionnement qui est décrit dans la documentation, il n’y a aucun effet indésirable à prévoir (lié à ce point précis) à la suite de la conversion d’un volume HFS+ vers APFS.
En effet, tous les noms de fichiers étaient en NFD sur le volume HFS+ et seront repris tels quels, toujours en NFD, dans la version APFS du volume. Tout ce qui accède à ces noms de fichiers devrait donc logiquement continuer à fonctionner comme précécemment.

C’est seulement ensuite, une fois que des fichiers seront ajoutés ou d’autres renommés, qu’il peut se poser des problèmes pour certaines applications.

« Ce n’est absolument pas clair. »

Si, pourtant.

« Tu as l’air de penser que ça résout tous les problèmes »

Non (et j’ai expliqué dans mes réponses à Bigdidou quels types de problèmes pouvaient se poser).
Mais ça résoud tous les problèmes les plus gros, les plus évidents et les plus inacceptables.

Et les problèmes qui sont susceptibles de se poser dans certaines applications font partie d’une classe qu’on rencontre déjà avec HFS+, et donc on peut donc supposer qu’ils ont déjà été corrigés dans la plupart des logiciels concernés.

« Ce n’est en tout cas pas ce que je qualifierais d’élégant. »

Ça l’est pourtant. Certains trouve même que c’est bien plus élégant que la transformation des noms opérée par HFS+. Pour ma part, je trouve que c’est du même niveau, chaque approche ayant ses avantages et ses inconvénients. Mais on peut reconnaître à l’approche retenue pour APFS l’avantage de la cohérence, puisque la gestion des formes Unicode est maintenant faite de la même façon que la gestion de la casse.

« La documentation est inexistante si on est gentil, fucking abysmal si on est honnête. »

Et si on est vraiment honnête, on se rend compte que malgré le grand vide qui y règne, elle est parfaitement claire sur ce point précis et permet de savoir comment cette gestion des noms va fonctionner.

Notons aussi qu’il a été annoncé qu’une documentation plus étoffée était actuellement en cours de rédaction. On peut certes regretter qu’elle ne soit pas arrivée plus tôt, mais évitons au moins de prétendre qu’on est convaincu qu’elle n’existera jamais.

« Ce merdier autour d’APFS à un trimestre de la sortie officielle, avec des beta publiques dispo, ne va pas remonter le score. »

Dire qu’à une époque, on pensait que les versions beta servaient justement à ça… ;-)

Franchement, maintenant que cette histoire de gestion des noms a été éclaircie et que cette solution a été adoptée, je n’ai plus d’inquiétude à ce sujet.

Les bugs, les vrais, comme ceux liés aux snapshots, me font plus peur.

avatar fte | 

@BeePotato

"les plus évidents"

Les plus évidents n’auraient jamais dû être résolus au stade de la beta. Peut-être pour une app mobile à 30k CHF, pas pour le FS du futur de millions d’ordinateurs de la plus grande entreprise du monde.

"Ça l’est pourtant."

L’élégance est subjective.

"Et si on est vraiment honnête, on se rend compte que malgré le grand vide qui y règne, elle est parfaitement claire sur ce point précis et permet de savoir comment cette gestion des noms va fonctionner."

Nous n’avons pas le même niveau d’exigence. Mais c’est OK.

"mais évitons au moins de prétendre qu’on est convaincu qu’elle n’existera jamais."

Je n’ai jamais prétendu ça.

"Dire qu’à une époque, on pensait que les versions beta servaient justement à ça… ;-)"

Cette époque est maintenant. Parce qu’il y a 10 ans, beta signifiait design achevé, tests structurels internes achevés, feature complete, et finitions amorcées. La beta de 2017 est l’early alpha des années 2000. On parle quand-même d’un composant crucial d’un OS.

Je ne suis pas aussi indulgent que toi. J’ai mis fin à des relations commerciales pour moins grave que ceci.

avatar BeePotato | 

@ fte : « Les plus évidents n’auraient jamais dû être résolus au stade de la beta. »

Ça, c’est vrai, et je l’ai déjà dit : je trouve ahurissant que cette gestion des noms n’ait pas été faite correctement dès le début.

« Peut-être pour une app mobile à 30k CHF, pas pour le FS du futur de millions d’ordinateurs de la plus grande entreprise du monde. »

Mouais. Ce n’est pas pour chercher une excuse aux gugusses qui ont géré ça, mais il faut rappeler que la famille d’OS la plus répandue sur des milliers (ou millions ?) de serveurs utilisés par le monde entier se traîne la même approche pourrie de (non-)gestion des conflits de noms de fichiers. Et sans qu’il y ait un correctif dans une version beta.

C’est malheureusement le genre de chose qui arrive.

« L’élégance est subjective. »

Alors pour éclairer ton point de vue sur le sujet, pourais-tu nous indiquer ce que tu trouverais élégant comme solution pour gérer ce point des noms de fichiers ?

« Nous n’avons pas le même niveau d’exigence. Mais c’est OK. »

Il ne s’agit nullement de niveau d’exigence. C’est juste un fait. La documentation est (maintenant) claire sur ce point précis. C’est indiscutable (sauf si on n’est pas en mesure de comprendre ce qui est dit dans ce passage de la doc).

« Je ne suis pas aussi indulgent que toi. J’ai mis fin à des relations commerciales pour moins grave que ceci. »

Et bien c’est stupide — pour ce qui est d’APFS dans Mac OS — puisque c’est sur le produit fini qu’on juge et non sur une pré-version.

En revanche, pour ce qui est d’APFS dans iOS, là, je suis bien d’accord qu’il est parfaitement honteux de l’avoir déployé dans cet état (car là, on parle bien du produit fini, vendu et tout).

avatar fte | 

@BeePotato

Je ne suis pas designer de fs. Je n’ai pas réfléchi au problème dans son contexte et je ne saurais proposer une solution.

C’est la raison pour laquelle je doute que ce qui est proposé soit une solution idéale, ou même seulement bonne. Je manque de recul et d’informations pour évaluer la pertinence de ce choix. Vu l’historique du problème, il est plus probable que ce soit une solution d’urgence mi-cuite.

C’est certainement approprié pour le Finder et les humains qui l’utilisent. Mais pour les développeurs, ça ne me semble pas fantastique de prime abord, probablement parce que j’ai eu ma dose de ? à dealer avec certaines stupidités d’UNICODE et ses évolutions pas toujours très .

"Et bien c’est stupide"

Merci.

"puisque c’est sur le produit fini qu’on juge et non sur une pré-version."

Oui, et non.

Version de développement, quelque soit le nom qui lui est donné, admettons.

Beta publique ? Non. Totalement non.

La fiabilité d’un produit se juge en particulier sur son historique, sur les versions disponibles pour tous, lâchées dans la nature. On parlerait de builds pour développeurs ou de versions distribuées à des personnes choisies, je ne tiendrais pas le même langage. Là, j’ai des gens qui me demandent s’ils devraient mettre à jour leur machine de boulot.

Apple ne rime vraiment pas avec fiabilité. Les produits pro abandonnés sans crier gare, le système qui disfonctionne des mois et des mois sur des points essentiels, des features qui disparaissent des apps et la compatibilité avec les anciens formats de fichiers très optionnelle, un fs avec des défauts de design majeurs livré au public... j’ai aimé Apple il y a 10 ans, il y a 20 ans, il y a 30 ans. Apple a fait de la merde parfois. Apple fait de la merde aujourd’hui.

avatar feefee | 

@fte

"j’ai aimé Apple il y a 10 ans, il y a 20 ans, il y a 30 ans. Apple a fait de la merde parfois. Apple fait de la merde aujourd’hui."

Peut être parce que les systèmes , les fonctionnalités, et les exigences changent ? Non ?
Et qu’ils sont de plus en plus durs à appréhender .

Maintenant si tu nous prouves que chez les autres c’est l’inverse ou que c’est mieux alors là ok ...

Au lieu de focaliser sur Apple , analyse le problème dans sa généralité ... Apple n’est qu’un des acteurs .
À moins que tu ne connaisses que ça ?

avatar BeePotato | 

@ fte : « Je ne suis pas designer de fs. Je n’ai pas réfléchi au problème dans son contexte et je ne saurais proposer une solution. »

Cette humilité t’honore. Cependant, dans ce cas, pourquoi ne pas t’y tenir en admettant que, pour la même raison, tu ne saurais affirmer que la solution retenue n’est pas bonne ?

« Je manque de recul et d’informations pour évaluer la pertinence de ce choix. »

Dans ce cas, pourquoi sembler aussi convaincu que c’est une mauvaise solution ?

« Vu l’historique du problème, il est plus probable que ce soit une solution d’urgence mi-cuite. »

Non, ça ne l’est pas.
Ce n’est pas la solution idéale, tout simplement parce qu’il n’y en a pas. Mais ça reste une très bonne approche.
C’est une approche disponible aussi dans ZFS, soit dit en passant. Ça n’a rien d’une idée loufoque sortie à l’arrache par un développeur d’Apple.

« C’est certainement approprié pour le Finder et les humains qui l’utilisent. »

Ben ça tombe bien, puisque c’est justement ce qui compte !

« Mais pour les développeurs, ça ne me semble pas fantastique de prime abord, probablement parce que j’ai eu ma dose de ? à dealer avec certaines stupidités d’UNICODE et ses évolutions pas toujours très . »

L’approche utilisée dans HFS+, à laquelle on était habitué jusque là, ne nous préservait pas d’être confrontés aux subtilités d’Unicode.
Et j’ajouterai qu’un développeur qui ne veut pas avoir à faire une gestion propre de chaînes en Unicode devrait se tenir à l’écart de tout développement impliquant une manipulation de chaînes de caractères destinées à être affichées à l’utilisateur — ce qui inclut donc les noms de fichiers — au lieu de réclamer une solution qui lui permettrait de mal faire son travail.
Enfin, pour ce qui est du tri et autres comparaisons de chaînes de caractères Unicode, il y a suffisamment d’API disponibles dans Mac OS pour qu’on n’ait pas à se poser beaucoup de questions au moment de manipuler des noms de fichiers qui n’auront pas été normalisés.

« La fiabilité d’un produit se juge en particulier sur son historique, sur les versions disponibles pour tous, lâchées dans la nature. »

Sur les versions finales disponibles pour tous. Celles « vendues » (même quand elles sont proposées gratuitement) comme faisant le travail pour lequel elles ont été conçues.
Pas sur les versions de développement, fussent-elles disponibles pour le public, puisqu’il est bien annoncé qu’elles sont incomplètes.

« Là, j’ai des gens qui me demandent s’ils devraient mettre à jour leur machine de boulot. »

On touche là au problème des bêtas publiques — ainsi que du public bêta ;-).
De mon point de vue, ce n’est pas une très bonne idée.

« Apple a fait de la merde parfois. Apple fait de la merde aujourd’hui. »

Apple fait de la merde parfois aujourd’hui.
Tu avais oublié un « parfois ». ;-)

avatar fte | 

@BeePotato

Tu ne m’as pas compris je pense. Je ne suis pas convaincu que c’est une mauvais solution.

Je ne suis pas convaincu que s’en est une bonne.

Et il n’y a pas de doute que c’est une solution très tardive à un défaut de design critique détecté très tardivement. Beaucoup trop tardif.

Qu’il y ait des différences de comportements du fs portant le même nom et mêmes API dans iOS et macOS n’est pas très judicieux je pense.

La grande différence entre nos points de vue n’est pas bonne / mauvaise solution, la différence est que tu es convaincu que alors que je doute que. Je ne sais pas ce qui t’a convaincu aussi fortement, peut-être est-ce ta spécialité professionnelle, pour ma part ce n’est pas ma spécialité et j’ai besoin de plus d’info et d’expérience avec la chose et son comportement pour que la confiance puisse s’établir.

Ce n’est pas le processus de design bien dégeulasse d’APFS qui donne confiance, ni le récent track record d’Apple. Récent = ces 5 dernières années au moins.

Disons-le différemment : c’est peut-être une excellente solution, et peut-être qu’APFS se révèlera un excellent fs pour les 20 prochaines années au moins. (J’espère !) C’est à Apple de le prouver et de convaincre.

avatar BeePotato | 

@ fte : « Tu ne m’as pas compris je pense. Je ne suis pas convaincu que c’est une mauvais solution. Je ne suis pas convaincu que s’en est une bonne. »

En effet, je n'avais pas compris ça comme ça, désolé.
En partie parce que je suis resté influencé par ton « ça pue » initial, alors qu'il portait sur la version précédente d'APFS. Mais aussi parce que tu qualifie la version actuelle de « plus que probablement une solution d'urgence mi-cuite », ce qui m'évoque, plutôt qu'un simple doute, une tendance à pencher vers l'hypothèse que la solution est mauvaise.

« Et il n’y a pas de doute que c’est une solution très tardive à un défaut de design critique détecté très tardivement. »

Oui.

« Beaucoup trop tardif. »

Non. Dans le cas de Mac OS, du moins — puisque ce défaut a été corrigé avant la sortie de la version finale, la seule qui compte.

Pour iOS, c'est une autre histoire…

« Qu’il y ait des différences de comportements du fs portant le même nom et mêmes API dans iOS et macOS n’est pas très judicieux je pense. »

Il s'agit du même FS mais utilisé avec des options différentes, ce qui était déjà le cas jusqu'à maintenant avec HFS+. Rien de choquant pour moi du point de vue « technique » (pour les développeurs, quoi).
En revanche, je n'ai jamais bien compris la motivation de ce choix, ni trouvé que c'était une bonne idée pour les utilisateurs.

« Je ne sais pas ce qui t’a convaincu aussi fortement, peut-être est-ce ta spécialité professionnelle, pour ma part ce n’est pas ma spécialité et j’ai besoin de plus d’info et d’expérience avec la chose et son comportement pour que la confiance puisse s’établir. »

Ben je trouve que le fonctionnement prévu est bien décrit, ce qui permet, quand on est développeur, de voir assez facilement ce que ça donnera, quels problèmes ça évitera et quel type de problèmes ça génèrera. Le fait qu'il y ait déjà une bonne variété d'approches de ce sujet utilisées dans les divers FS et OS du marché aide aussi beaucoup à se rendre compte des diverses classes de problèmes possibles.

« Ce n’est pas le processus de design bien dégeulasse d’APFS qui donne confiance »

Le truc, c'est qu'en dehors de la façon dont a été gérée cette histoire de noms de fichiers, on n'a aucune connaissance du processus de design d'APFS. Donc le qualifier de « bien dégueulasse » est très exagéré.

« C’est à Apple de le prouver et de convaincre. »

Pas d'accord : c'est l'usage de ce FS qui permettra de le prouver et de nous convaincre (dans un sens ou dans l'autre).

avatar Bigdidou | 

@BeePotato

« Cette approche n’est pas la même que celle utilisée dans HFS+, où les noms étaient tous normalisés de la même façon avant d’être enregistrés dans le FS. Avec APFS, ils seront conservés tels que fournis par les clients du FS, mais les comparaisons de noms seront insensibles à la normalisation choisie pour tel ou tel caractère (ce qui revient à dire qu’ils sont convertis à la même normalisation avant d’être comparés, quoi).
C’est cette seconde partie qui manquait jusque là et qui générait les problèmes que tu as cités »

C’est intéressant, mais j’ai rien compris. Le problème c’est que j’ai l’impression que c’est important de comprendre si’il a des problèmes au niveau des applications « mal codées ».

Si tu as le temps, est-ce que tu pourrais expliquer de façon concrète la chose ?
Si j’entre un nom de fichier qu’est-ce que le système comprend, qu’est ce qu’il stocke, et pourquoi ça peut poser problème au niveau des applications ?
Alors il y a des noms de fichiers qu’on ne maitrise pas, ceux du système et des applications : est-ce qu’il faut craindre l’apparition de bugs majeurs dans certaines applications mal mises à jour à case de ça ?
Sinon, pour les noms qu’on donne à des fichiers ou dossiers, est-ce qu’il y a des précautions à prendre le temps que tout ceci s’installe et les applications qui pourraient avoir du mal;soient mises à jour ?

avatar BeePotato | 

@ Bigdidou : « Si tu as le temps, est-ce que tu pourrais expliquer de façon concrète la chose ? »

Ok. Posons d’abord le problème : il vient du fait que certains caractères peuvent être représentés de plusieurs façons en Unicode. L’exemple classique cité est le « é », qui peut être exprimé sous la forme d’un caractère unique (comme c’était le cas dans les anciens jeux de caractères) ou décomposé en « e+´ » (plus logique à mon avis).
Quand on compare deux chaînes de caractères (par exemple deux noms de fichiers) pour un usage par un humain, on s’attend à ce que ces deux formes soient considérées comme la même chose, histoire que le mot « été » soit considéré comme toujours le même quelles que soient les représentations choisies pour ses deux « é ».

La solution adoptée pour ça dans HFS+ a été de transformer tous les noms de fichiers en forme décomposée (« e+´ », donc) avant de les enregistrer sur le disque. Et donc, logiquement, de transformer tout nom fourni au FS quand on recherche un fichier, histoire qu’il soit facilement comparable à ceux des fichiers sur le disque.

L’approche adoptée pour APFS correspond plus à ce qui est fait dans beaucoup d’autres FS : enregistrer le nom d’un fichier tel qu’il est fourni par l’application, donc avec des caractères dont on ne sait pas s’ils sont sous forme précomposée ou décomposée.
Le hic, c’est qu’initialement, la comparaison des noms de fichiers était faite de façon basique, donc sans faire l’équivalence entre les deux formes, ce qui autorisait d’avoir au même endroit jusqu’à quatre fichiers nommés « été ». Et surtout, ça ne permettait pas à une application de retrouver facilement un fichier par son nom, vu qu’il fallait le demander avec la même forme que ce qui était enregistré sur le disque. Ça, c’est un problème qu’on rencontre régulièrement sur les Linux, notamment, où on utilise beaucoup de FS fonctionnant de cette façon.

Mais c’est maintenant réglé par la dernière version d’APFS, qui fait proprement les comparaisons de noms de fichiers. Ce qui permet de retrouver un fichier par son nom même si on ne l’écrit pas de la même façon que lors de sa création. Et ce qui interdit, par la même occasion, de créer deux fichiers du même nom différant uniquement par le forme composée ou non, puisque ces deux noms seront considérés comme identiques.
On retrouve quelque chose de bien plus logique, quasiment identique à ce qu’on avait avec HFS+.

« Quasiment », car il reste une différence : quand une application liste le contenu d’un dossier en APFS, elle récupère les noms de fichiers tels qu’ils ont été fournis lors de la création des fichiers, alors qu’avec HFS+ elle récupère des noms de fichiers tous normalisés de la même manière.
Une application qui se reposait sur le fait que les noms étaient tous normalisés de la même façon pour se contenter d’en faire une comparaison basique pourra donc rencontrer des soucis avec APFS.

avatar Bigdidou | 

@BeePotato

Merci, c’est extrêmement clair vraiment très intéressant ;)

avatar BeePotato | 

@ Bigdidou : « est-ce qu’il faut craindre l’apparition de bugs majeurs dans certaines applications mal mises à jour à case de ça ? »

Pas trop, non. Le souci que j’ai évoqué affectera surtout des choses comme l’ordre de tri des noms de fichiers dans les applications non adaptées.

Le seul cas ou ça peut poser un souci majeur est pour une application comparant le contenu de deux dossiers, et considérant que des fichiers au nom identique dans les deux dossiers n’ont pas le même nom en raison d’une différence de normalisation entre les deux. Les applications reposant sur ce principe (les systèmes de gestion de versions, notamment) sont donc à surveiller.

« Sinon, pour les noms qu’on donne à des fichiers ou dossiers, est-ce qu’il y a des précautions à prendre le temps que tout ceci s’installe et les applications qui pourraient avoir du mal;soient mises à jour ? »

Quand on nomme directement ses fichiers et dossiers depuis un Mac, il n’y a pas vraiment à se poser de question.
Ce sont les fichiers venus d’ailleurs qui sont susceptibles de voir leur nom utiliser une autre normalisation.

avatar feefee | 

@fte

"compréhensible pour de l’électroménager, vu que c’est ce que fabrique Apple maintenant"

ha mais oui et c’est tant mieux pour tous les utilisateurs de la planète .
S. Jobs et donc Apple a toujours voulu faire de l’ordinateur une brique de notre électroménager .
Et heureusement encore .
Il n’y a a que les informaticiens pur jus, qui ont toujours voulu garder l main et leur supériorité face aux soit disants ignorants non digne d’extraire la substantifique moelle d’un ordinateur , qui peuvent voir là dedans un recul quelconque .

Mais je comprends bien que pour bon nombre c’est tuer la poule aux œufs d’or .

Non c’est bien une avancée qu’IBM n’a jamais réellement souhaitée et que MS a toujours voulu faire sans jamais y parvenir complètement.

Pages

CONNEXION UTILISATEUR