Carbon Copy Cloner (partiellement) compatible avec macOS High Sierra
La mise à jour vers macOS High Sierra ne changera pas grand-chose en apparence, mais modifiera des pans entiers du système en profondeur. De quoi poser des problèmes à certains utilitaires, comme Carbon Copy Cloner, directement touché par l’arrivée d’un nouveau système de fichiers.
Une première préversion de CCC 4.1.16 règle les problèmes les plus pressants, mais l’application de clonage de disques est encore loin d’être parfaitement compatible avec macOS High Sierra. Elle est capable de copier des fichiers depuis et vers un volume APFS, de créer un clone bootable d’un volume APFS sur un volume HFS+… et c’est à peu près tout.
« Créer un volume APFS bootable, par contre, c’est un saut vers l’inconnu », explique Mike Bombich, le créateur de Carbon Copy Cloner. « Nous avons déjà établi une procédure de création d’un volume de démarrage APFS », dit-il, mais il reste encore à la graver dans le code de CCC, et surtout à prendre correctement en charge les nouveaux mécanismes de chiffrement du système de fichiers.
Si la chose est compliquée pour Bombich, elle l’est plus encore… pour Apple elle-même. Time Machine, le système de sauvegarde incrémentielle intégré au système, fait un grand usage des liens matériels… qu’APFS ne prend pas en charge. Dans l’état actuel de macOS High Sierra, la sauvegarde d’un volume APFS sur un volume APFS est largement impraticable.
Des problèmes avec la compatibilité de certaines applications dans macOS High Sierra ? Faites-le savoir dans nos forums !
Et donc, quel est l'état de Time Machine dans la bêta 1 de High Sierra ?
Ça fonctionne toujours ? Sur disque HFS+ ?
@iGeek07
Sur HFS+ ça risque fort de ne rien changer (c'est peut-être là la clé de l'option pour passée à l'APFS, ceux qui veulent encore sauvegarder avec TimeMachine n'ont pas intérêt à évoluer immédiatement vers APFS)
Ben y a 2 approce avec timeMachine:
- avec un disque local (FireWire / Thunderbolt /USB)
- avec un disque reseau (NAS / serveur local / cloud)
Avec un disque reseau, normalemnt c'est une image disque qui est cree, donc peu importe le systeme de fichiers.
Avec un disque local ça va devenir plus compliqué, surtout si on choisi l'option de chiffrement. Mais la Apple va bien trouver la bonne solution...?
Ce qui est certain c'est que le systeme de fichier proprietaire d'Apple va imposer une reecriture des soft (tous) qui gerent l'etat des disques, les backup, l'organisation et la navigation.
Ensuite il y a ceux qui faire payer au prix fort cette mise a jour et ceux qui vont la considerer comme une fonction... et puis il y a ceux qui vont partir sur une toute nouvelle version ou un nouveau soft, plien tarif... et un passage au modele d'abonnement :(
Un soft comme DiskWarrior a également un gros travail de réécriture complète... la mise à jour risque d'être facturée plein pot.
"des liens matériels… qu’APFS ne prend pas en charge": say whooooot? ?
Comment ça marche pour les utilitaires comme Homebrew ou autres qui installent des apps de type Unix? Ceux-ci sont très largement dépendants des liens matériels. Quelqu'un a essayé? Curieux des retours, merci!
@YAZombie
""des liens matériels… qu’APFS ne prend pas en charge"
Excuse ma question de Beotien, mais c'est quoi, un lien matériel ?
C'est la même chose que les liens symboliques ?
Ça va être un gros bordel s'ils sont pas pris en charge, j'ai du mal à imaginer ça.
Ou alors ce nouveau système de fichier est tellement différent de hfs+ que les liens symboliques n'y ont plus de sens ?
@Bigdidou
Si j'ai bien compris, APFS gere toujours les liens symboliques et alias. Par contre il ignore les hard links.
En gros un lien symbolique est juste un fichier texte pointant vers un fichier dans le catalogue de fichier.
Un hard link donne l'emplacement d'enregistrement du fichier sur le disque directement.
Un fichier et un lien symbolique vers ce fichier sont 2 fichiers distincts alors qu'un fichier et un hardlink vers ce fichier représentent un seul et même fichier.
Voilà je ne sais pas si c'est plus clair.
(Sinon recherche sur Google "unix symlink vs hardlink"
@r e m y
Merci, r e m y.
C'est parfaitement clair, et ouf !
Toute mon organisation à revoir, sans les liens symboliques, et je suis certainement pas le seul ;)
@Bigdidou
Non les liens symboliques subsistent! Ce sont les hard links qui ne sont plus autorisés par APFS.
@r e m y
"Non les liens symboliques subsistent! Ce sont les hard links qui ne sont plus autorisés par APFS."
Oui, oui, j'ai bien compris, mais je me suis mal exprimé ;)
Toute mon organisation SERAIT à revoir sans les liens symbolique. Ouf qu'ils n'aient pas disparu.
Ce qui disparait ou est remplacé, sont ces fameux hard links dont on a entendu parler ici avec la photothèque dans plusieurs endroits sans que cela augmente la place prise sur le dd. Ca avait pas été simple à comprendre, et je crois pas avoir encore totalement bien appréhendé le concept,
Si j'ai bien compris, un système va reprendre ça puissance 1000 et le généraliser avec APFS et HS, normal que les hard links tels qu'on les connait disparaissent, au fond.
Excellente remarque sous la forme de question! J'ai en effet été trop prompt à comprendre "lien symbolique", mais apparemment ce n'est pas la même chose.
Merci r e m y pour les précisions. J'imagine que du coup pas d'influence pour la compatibilité des apps venues du monde Unix/Linux (?).
Je me faisais la remarque qu'on avait pas entendu parler de Time Machine, qui devrait pourtant profiter du passage à APFS (certainement au prix d'une refonte quasi totale).
Quelqu'un a creusé le sujet ? La rédaction ?
Excellente solution de sauvegarde, très bon produit que je recommande en parallèle avec TM.
Et qu'en sera-t-il des Time Capsule ? Est-ce pour ca qu'Apple ne les renouvelle pas ?
@Sebang
Les rumeurs indiquent qu'Apple a abandonné toutes ses bornes wifi et donc y compris TimeCapsule.
L'avenir selon Apple, est à la sauvegarde en temps reél sur son iCloud Drive (dossier documents et desktop), le système etant reinstallable depuis internet et les applications retelechargeables depuis l'appStore.
"L'avenir selon Apple, est à la sauvegarde en temps reél sur son iCloud Drive"
Non. iCloud Drive n'est pas une sauvegarde, mais un stockage déporté avec système de synchronisation. iCloud Drive ne vous sauvera pas un fichier supprimé par erreur, par exemple.
@patrick86
Pour l'instant, oui. Mais ca pourrait évoluer.
Sur www.icloud.com on peut deja récupérer quelques éléments parmi les infos synchronisées en cas d'effacement accidentel. C'est un début.
"Sur www.icloud.com on peut deja récupérer quelques éléments parmi les infos synchronisées en cas d'effacement accidentel."
Parce qu'il y a une sauvegarde de ces données.
@r e m y
En gros l'horreur pour beaucoup de professionnels! La sauvegarde locale doit rester possible sinon ce sera encore un pas de plus vers Linux et rsync!
Il va aussi falloir surveiller comment les apps se comportent avec les fichiers et dossiers dont les noms comprennent des caractères accentués.
https://eclecticlight.co/2017/04/06/apfs-is-currently-unusable-with-most-non-english-languages/
https://eclecticlight.co/2017/04/05/file-problems-in-ios-10-3-and-macos-10-13-whats-in-a-name/
@patrick86
Apple a répondu que ce n'est pas un bug mais un choix dans la façon de gérer Unicode. Il faut que les développeurs utilisent les API du système si ils ne veulent pas avoir de soucis dans la conversion des caractères accentués et spéciaux.
@r e m y :
J'avais compris que c'était un choix et non un bug, mais n'était pas au courant de la réponse d'Apple. ?
@patrick86
Les réponses données dans les forums développeurs ont été synthetisees dans la FAQ officielle https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html
To avoid introducing bugs in your code with mismatched Unicode normalization in filenames:
Use high-level Foundation APIs such as NSFileManager and NSURL when interacting with the filesystem
Use the fileSystemRepresentation property of NSURL objects when creating and opening files with lower-level filesystem APIs such as POSIX open(2), or when storing filenames externally from the filesystem
@r e m y :
Ah oui, j'avais lu cela dans les articles du même auteur [que j'ai cité]. Mais du coup, je réitère mon observation, puisque dans la mesure où les logiciels n'utilisent pas les API NSFileManager et NSURL, certaines risquent de mal gérer les caractères Unicode dans les noms de fichiers et dossiers.
@patrick86
Oui c'est un vrai risque effectivement et ça peut mettre un joli souk...
Pages