Microsoft commence à déployer ReFS, son concurrent d'APFS
Il y a quelques jours, Microsoft a ajouté en douce la prise en charge du système de fichiers ReFS dans une version bêta de Windows 11. Et comme pour le passage du HFS+ à l'APFS il y a quelques années chez Apple, c'est important pour Microsoft.
Un remplaçant du NTFS
NTFS (pour New Technology File System) a été introduit en 1993 avec la première version de Windows NT, la 3.11. Il a longtemps été utilisé en parallèle de FAT16 et FAT32 avant de devenir le système de fichiers par défaut avec Windows XP en 2001, qui fusionnait les branches 9x et NT de Windows. Le NTFS est en gros un contemporain du HFS+, apparu en 1998 avec Mac OS 8.1, qui a été remplacé en 2017 par l'APFS (Apple File System).
Comme souvent chez Microsoft, la transition du NTFS vers ReFS (pour Resilient File System) est assez longue. Le « nouveau » système de fichiers a été introduit en 2012 avec Windows Server 2012, le pendant professionnel de Windows 8. Au fil des années, il a été amélioré et pris en charge par d'autres versions de Windows, mais toujours dans un contexte professionnel jusqu'à maintenant.
Un système de fichiers moderne
ReFS est un système de fichiers qui ressemble à l'APFS sur certains points, avec des mécanismes de sécurité intégrés pour éviter les corruptions de données, comme la technologie copy-on-write. Pour simplifier, si vous effectuez une écriture quelconque avec un système de fichiers classique, les nouvelles données peuvent être écrites à la place des anciennes, dans le même bloc que les anciennes du point de vue du système de fichiers.
Ce choix pose un problème : si jamais un problème survient pendant l'écriture, les données sont perdues. Avec la technologie copy-on-write utilisée par APFS et ReFS, les nouvelles données sont écrites sur un bloc vide et les liens qui pointent vers les données ne sont modifiés qu'une fois l'écriture validée. Ce choix permet de garder une copie des données grâce aux *snapshots*, avec la possibilité de revenir en arrière rapidement. En cas de problème, le média contient donc les anciennes et les nouvelles données.
Par rapport à NTFS, ReFS prend en charge de plus grandes partitions (35 Po contre 256 To), avec une taille maximale identique pour les fichiers. Il gagne aussi quelques options qui accélèrent les grappes RAID en mode logiciel, et perd seulement quelques options peu utilisées en NTFS. La page dédiée de Microsoft indique que la gestion des noms courts n'est plus possible2 et que le ReFS ne peut pas être utilisé comme disque de démarrage… ce qui est faux.
C'est en effet la nouveauté de la dernière version bêta de Windows 11 : il est possible d'installer l'OS sur un volume formaté en ReFS et de démarrer dessus.
Enabling ID 42189933 will allow you to install Windows to a ReFS partition without any other workarounds! pic.twitter.com/YO6aieo0fl
— Xeno (@XenoPanther) January 20, 2023
Reste à voir comment Microsoft va effectuer la transition. Apple avait poussé la migration vers APFS en douce avec iOS 10.3 et plus ou moins imposé le système de fichiers avec macOS High Sierra, avec quelques exceptions. Mais dans le monde Windows, l'inertie est la norme et la rétrocompatibilité souvent importante, sans même prendre en compte la myriade de configurations différentes. Plus pragmatiquement, le ReFS ne devrait pas remplacer le NTFS en masse très rapidement et c'est un peu dommage.
Notons enfin que le ReFS est pour le moment un projet fermé et qu'il n'existe pas de pilotes pour lire le ReFS sous macOS. Pour GNU/Linux, Paragon propose un pilote payant et fermé.
@ Doctomac : « C'est à dire ce qu'il est possible de faire sur Mac déjà depuis HFS+. »
Sur Mac, ça n’a (heureusement) pas attendu HFS+.
Mais comme d’autres l’ont déjà fait remarquer, ce n’est pas lié au système de fichiers, mais au fonctionnement des bibliothèques se trouvant au-dessus, à leurs API, ainsi qu’à la façon dont les applications gèrent les accès aux fichiers. Toutes choses qui ne sont pas près de changer.
AMHA, la note 2 est pleine d'erreurs, il ne faut utiliser que des MAJUSCULES...
@ fte : « C’est toi qui l’a dit, pas moi. »
Nope. Jamais dit ça.
Je crois que tu as juste mal interprété une phrase (ce qui n’existe pas, c’est le rapport, pas le dossier Documents).
« Tu t’attends à quoi dans un thread initié par Doctomac dans lequel tu adoptes le même style ?! »
Le même style, c’est quoi ? Signaler que c’est une grossière exagération (un troll, quoi) que d’expliquer que cette fonction ne fonctionne que dans une minorité de cas ?
« Des arguments ? Sérieusement. »
Oui. Des arguments techniques justifiant pourquoi cette fonction serait inopérante dans une majorité de cas. Ou, à défaut d’arguments techniques, au moins une liste de cas que tu aurais observés, dans lesquels ça ne fonctionnerait pas.
Par curiosité. Et parce qu’il est toujours bon d’accorder le bénéfice du doute à son interlocuteur — ça peut toujours être l’occasion d’apprendre quelque chose.
« Je te donne des pistes : »
Merci.
« dossier cible en lecture seule »
L’utilisateur ne peut pas déplacer le fichier, il n’est donc même pas la peine de se demander ce que ferait l’application si on arrivait à le déplacer — que fait ce cas dans cette liste, si ce n’est du pur remplissage pour en gonfler artificiellement la taille ?
« dossier cible en écriture seule »
Le suivi du fichier fonctionne très bien dans ce cas, en tout cas sur HFS+ et APFS (donc dans la majorité des situations pour un utilisateur de Mac), ce qui est normal vu leur fonctionnement. Sur certains autres systèmes de fichiers (ceux où il est nécessaire de lire le répertoire pour connaître le nom d’un fichier qui s’y trouve), j’imagine que ça ne devrait pas fonctionner — c’est donc le cas qui fait que ma réponse à Doctomac était partiellement incorrecte : cette fonction dépend bien en partie des capacités du système de fichiers. 🙂
« volumes réseau »
J’utilise cette fonction régulièrement et sans problème sur des montages en SMB.
Ça marchait bien aussi sur AFP.
Ça fait trop longtemps que je n’ai plus monté de NFS sur mon Mac pour me rappeler comment ça se comportait — mais je crois bien qu’on sera d’accord pour classer un tel cas comme minoritaire. 😉
« volume cible différent… »
Techniquement, il ne s’agit plus alors du même fichier (il s’agit d’une copie sur le volume cible, suivie d’une suppression du fichier d’origine). Mais c’est une subtilité qui n’a pas tellement de sens pour un utilisateur lambda. Il y a 40 ans, on attendait des utilisateurs qu’ils connaissent et comprennent ce principe. Il y a 30 ans, ils devaient le connaître et l’accepter (pas forcément besoin de le comprendre). De nos jours, on en arrive enfin à admettre qu’un tel détail d’implémentation de ce qu’est un fichier ne devrait pas être exposé (et imposé) à un utilisateur normal.
Du coup, cette fonction de suivi a été adaptée à cette logique et ça marche. 🙂
Lorsqu’un fichier est déplacé d’un volume vers un autre via le Finder (là encore, cas majoritaire pour les utilisateurs de Mac), le suivi fonctionne bien et l’application accède au fichier à son nouvel emplacement.
« application qui maintient un fichier ouvert vs application qui ferme et réouvre le fichier… »
Notons qu’une application qui maintiendrait un fichier ouvert tout le temps de son édition (j’utilise le conditionnel car ça ne se fait plus trop, en tout cas sur Mac) n’aurait pas besoin, pour continuer à lire et écrire dans ce fichier, de suivre ce qui lui arrive en termes de déplacement/renommage (mais bien sûr, sans ce suivi elle ne pourrait pas garantir d’afficher correctement à l’utilisateur des informations sur le nom et l’emplacement du fichier).
On s’intéresse donc ici plutôt au mode de fonctionnement classique de l’édition de document, où l’application ne garde le fichier ouvert que le temps de le lire ou d’y écrire, et le reste du temps conserve juste une référence pour pouvoir y accéder plus tard.
La différence est donc plutôt, comme je l’ai indiqué précédemment, entre les applications conçues pour MacOS (et utilisant donc les bonnes API pour suivre les fichiers) et celles conçues pour d’autres plateformes (ou pour aucune en particulier). C’est là que, selon les usages de chacun, on peut se retrouver à utiliser une majorité d’applications faisant bien les choses, ou une majorité d’applications les faisant mal (pour ce sujet particulier, et l’adaptation à l’OS en général — je ne parle pas des fonctions principales de l’application).
Mais si on se retrouve à utiliser majoritairement des applications non conçues pour le Mac et n’exploitant pas les spécificités de MacOS, on devrait à mon avis commencer à se demander (comme tu l’as apparemment fait) pourquoi on n’utilise pas un autre OS.
« il y a tellement d’inconsistances que la seule possibilité crédible pour penser que c’est consistant est de ne pratiquement jamais s’en servir. »
Ou de s’en servir très régulièrement et de savoir de quoi on parle, sans chercher à troller. 😉
Merci encore pour cette liste, qui m’a permis de confirmer ce que je pensais.
@BeePotato
"Je crois que tu as juste mal interprété une phrase"
Très possible. Mes excuses si c’est le cas. C’était cohérent avec l’ambiance générale du fil.
"Le même style, c’est quoi ?"
Des affirmations balancées.
"Signaler que c’est une grossière exagération"
Nous ne seront pas d’accord sur ce point je suppose.
"un troll, quoi"
Oui oui, les avis différents sont des trolls, internet, normal.
"que d’expliquer que cette fonction ne fonctionne que dans une minorité de cas ?"
Je n’ai pas dit ne fonctionne pas. J’ai dit inconsistant.
Je n’ai jamais dit minorité. Ni majorité. J’ai dit ni l’un ni l’autre.
L’exagération n’est pas là où tu crois qu’elle est.
"« dossier cible en lecture seule »
L’utilisateur ne peut pas déplacer le fichier"
Si on ne peut lire mais ajouter (macOS acl append, ou peut-être add_file, je ne sais pas la man page par cœur), on peut déplacer le fichier. Avec des conséquences.
"si ce n’est du pur remplissage pour en gonfler artificiellement la taille ?"
Pardon. Je donne une piste dont tu ne saisis pas immédiatement les détails techniques et du coup ça devient du remplissage. Tu parlais pourtant de laisser le bénéfice du doute, non ? Le bénéfice du doute ne s’applique pas à tes certitudes je devine.
Afin d’écarter toute suspicion de remplissage j’aurais dû me limiter à trois lettres. Argumenter n’est pas la bonne approche, je le sais.
"Le suivi du fichier fonctionne très bien dans ce cas"
Le suivi oui, mais le comportement qui en découle est… possiblement problématique. Inconsistant tout au moins.
"ceux où il est nécessaire de lire le répertoire pour connaître le nom d’un fichier qui s’y trouve"
acl…
"j’imagine que"
Yep, beaucoup d’imagination.
"cette fonction dépend bien en partie des capacités du système de fichiers. 🙂"
Très indirectement. VFS compte comme système de fichier ?
"mais je crois bien qu’on sera d’accord pour classer un tel cas comme minoritaire. 😉"
Nope.
Comme je le disais, si on utilise le dossier Documents, aucun soucis. Ce n’est pas mon environnement normal cependant.
Bref. Je suggères man chmod puis quelques expérimentations locales et dans un environnement réseau. Je suggère aussi de jouer avec les permissions d’accès accordées aux applications.
"Merci encore pour cette liste, qui m’a permis de confirmer ce que je pensais."
Tu es libre de tes croyances. Je n’ai aucune ambition de convaincre qui que ce soit, le doute suffit.
@ fte : « Je n’ai aucune ambition de convaincre qui que ce soit »
Encore heureux, car il y aurait du boulot de recherche technique avant de pouvoir y arriver.
@BeePotato
"Encore heureux, car il y aurait du boulot de recherche technique avant de pouvoir y arriver."
Pas mon problème si tu es flemmard, hein. Ça ne m’en touche même pas une. Au cas où, tu peux commencer par developer.apple.com/documentation/foundation/filemanager.
Merci à Beepotato d’avoir humilié fte, c’était grandiose.
Pages