je voulais juste être certain que les deux systèmes coexistants ne sont pas totalement séparés et que les fichiers et dossiers du mac sont exploitables par les deux "à la fois". J'édite un word et enregistre une pièce jointe sur El Capitan. Je reboote sur High Sierra, et je retrouve ce word et cette pièce jointe.
C'est parfaitement possible.
Je suppose que tu as un compte dans l'OS «
El Capitan» et que ton nom-de-compte (nom court) est
alex. Lorsque tu opères dans «
El Capitan» (volume
Macintosh HD au format
Apple_HFS+ démarré) --> le volume
High Sierra est invisible (non monté, car dans un format
APFS non reconnu par le système de fichiers
JHFS+ plus ancien). Ton domaine d'opération sur des données est donc l'espace de ton dossier de compte
alex. Par exemple, un fichier
brol.doc est localisé à l'emplacement :
/Users/alex/Documents/brol.doc. En tant que propriétaire du dossier de compte
alex > tu as des permissions plénières
rwx (
read_write_execute) sur toute la profondeur d'objets du dossier
alex -->
nil obstat ! Tu fais ce que tu veux avec tes données.
Supposons à présent que tu rebootes sur «
High Sierra», recelé en tant que Système dans un volume éponyme
High Sierra. Si as pris le soin de créer un compte d'utilisateur admin dans «
High Sierra» qui ait exactement les mêmes identifiants que ceux de ton compte dans «
El Capitan» --> càd. pour l'essentiel qui importe
alex comme
nomcourt d'utilisateur > alors voici la conséquence --> le volume
JHFS+ Macintosh HD est parfaitement
reconnu par le système de fichiers
APFS (compatilibilité rétrograde) --> donc le volume
Macintosh HD est affiché monté, exactement comme celui de ton DDE, sur le Bureau de ta session
alex. Et comme il y a
exacte identité nominale entre le
alex de «
High Sierra» et le
alex d'«
El Capitan» > par
corroboration d'identités > si tu entres dans le volume
Macintosh HD > dans le répertoire
Users > dans le dossier de compte
alex --> aucun sens interdit ne s'affiche parce que tu es
identifié comme le même que le
alex d'«
El Capitan». Tu peux donc ouvrir > lire > éditer > enregistrer (par exemple) le document localisé pour toi at:
/Volumes/Macintosh\ HD/Users/alex/Documents/brol.doc.
Nil obstat ! C'est comme si le dossier de compte
alex d'«
El Capitan» était une « extension logique » de ton dossier de compte
alex de «
High Sierra».
Il existe un procédé alternatif puissant garantissant cet accès propriétaire à l'espace d'un autre volume > c'est de faire depuis la session de «
High Sierra» un
⌘I (
cmd I) sur l'icône du volume monté
Macintosh HD > ce qui ouvre une fenêtre d'information du
Finder > déverrouiller le cadenas d'administration > cocher la case tout en bas : "
Ignorer les autorisations de ce volume". Cette action édite (dans le volume démarré
High Sierra) un fichier
/var/db/volinfo.database stipulant au Système, au démarrage, l'instruction que le volume-cible doit être
monté pour la session de l'utilisateur connecté en mode
spécial (il faut
re-démarrer après cette action dans la fenêtre d'information du
Finder pour que l'instruction devienne active). Mode spécial = volume monté > non avec les permissions "
absolues" ou "
intrinsèques" des contenus du volume > mais avec les permissions "
relatives" ou "
apparentes" de l'
utilisateur connecté pour la session duquel monte le volume. Admirable subtilité ! Le volume
Macintosh HD non-démarré va donc être
monté pour la session alex de «
High Sierra» démarré avec les permissions propriétaires d'
alex > qui va pouvoir manipuler l'ensemble du volume
Macintosh HD comme une "
extension spatiale" de son propre compte. Mais ! aucune action d'
alex sur les objets de ce volume
ne va modifier les permissions "
intrinsèques" de ces objets. Une fois le volume
Macintosh HD re-démarré > rien n'a été modifié aux permissions qui affectaient ses objets. Tu pourrais avoir choisi une identité
zestedorange dans «
High Sierra» > l'option : "
Ignorer les autorisation de ce volume" te permettrait de tout manipuler dans
Macintosh HD comme si c'était ton dossier de compte étendu. Mais une fois re-démarré sur
Macintosh HD > aucune identité
zestedorange n'a affecté en quoi que ce soit le moindre objet de ton compte
alex : c'est toujours
alex le propriétaire des objets. Évidemment --> lorsqu'on ignore les autorisations sur un volume recelant un OS > il faut avoir le bon sens de ne pas tripoter les fichiers du système pour y semer la pagaille.
----------
oncernant le nouveau système de fichier APFS, créer une partition et y installer High Sierra aura une incidence là-dessus, sur la totalité du disque dur?
Aucune. Chaque partition d'un disque est une
tranche logique (
slice) : un
conteneur englobant une série de blocs logiques numérotés du n° tant au n° tant --> découpage enregistré dans les descripteurs de la table de partition
GPT (
GUID_Partition_Table) qui réside sur les
32 premiers blocs du disque. Le conteneur d'une partition a un
TYPE LOGIQUE a priori : càd. une
définition formelle de conteneur --> lui permettant d'accueillir une
variété de systèmes de fichiers d'une
même espèce, à l'exclusion d'une autre espèce. Par exemple, une partition Apple classique a le
TYPE LOGIQUE Apple_hfs, correspondant au code
af00, qui lui permet d'accueillir toute la variété des modes de systèmes de fichiers conformes au type
Apple_hfs :
hfs+, >
jhfs+ (journalisé) >
hfs+x (sensible à la casse) >
jhfs+x (journalisé, sensible à la casse). Et aucun autre.
Un
système de fichiers s'injecte donc dans le conteneur d'une partition dont le
TYPE LOGIQUE est défini a priori pour pouvoir l'accueillir. Ledit système de fichiers consiste en une structure logicielle de fichiers "coopératifs" > dont le rôle exclusif est de
définir l'espace de blocs bruts de la partition comme un "
espace de répertoire affichant des fichiers interprétables" : un "
volume". Un "
volume" est donc une
forme convertie de l'espace de blocs de la partition : une "manifestation" ou un "rendu logique". On dit par suite que le volume
monte sur les blocs de la partition comme sa "forme intelligible" (pour l'utilisateur - ce n'est qu'une « apparence logique », un « phénomène » dont l'« essence » demeure la distribution des blocs porteurs des écritures brutes de la partition). C'est donc la génération d'une "transformation" logique.
Le système de fichiers s'inscrit sur l'
en-tête de blocs du conteneur de la partition pour constituer ses "
headers" : les "en-têtes" opératoires de la partition.
Autant de partitions --> autant de
headers = systèmes de fichiers. Charbonnier maître chez lui ! Pas un atome du système de fichiers d'une autre partition ne vient contaminer / affecter etc. le système de fichiers "
headers" de telle partition. Le
jhfs+ "
headers" de la partition
disk0s2 --> permettant le montage "phénoménal" du volume
Macintosh HD --> ne subira pas la moindre "affection" logique de la contiguïté d'un système de fichiers
APFS sur la partition
disk0s4 --> montant un volume
High Sierra. Sur la partition
disk0s4 > l'
apfs consistera en une structure de
headers particulièrement sophistiquée : l'un re-définissant les blocs de
disk0s4 comme un "magasin de stockage physique" > l'autre définissant la "génération parallèle" d'une couche logique virtuelle
Container apfs =
disk1 > d'autres définissant des points de montage de volume aux fonctions diversifiées sur le disque logique virtuel du
Container etc.. => le système de fichiers
jhfs+ de la partition
disk0s2 "s'en fout royalement" : il ne "saura" jamais qu'un
apfs tarabiscoté s'amuse à contruire des tours de Babel logiques sur la partition d'à-côté > l'herbe n'est pas "plus verte" dans le pré de la partition du voisin > le
jhfs+, autarcique et narcissique, va se borner à sa transformation "phénoménale" simplet et classique : espace des blocs bruts de la partition
disk0s2 => répertoire de fichiers "apparemment" intelligibles d'un volume. Ça ne vole pas haut : pas de pyramide logique --> rien qu'un pré-fabriqué sans étage.
Si depuis le volume
apfs High Sierra tu agis sur des contenus du volume
Macintosh HD monté en mode stockage --> tu n'agis
pas sur le
système de fichiers jhfs+ de
Macintosh HD > tu n'agis que sur les objets intelligibles qu'il présente dans l'
espace de montage du répertoire du volume. Le système de fichiers permet le montage d'un volume à partir d'un
point de montage : un départ de "manifestation comme un répertoire", inscrit sur la partition = un
dev node (un nœud de
device). Opérer depuis le volume
apfs High Sierra reste confiné à l'
espace de répertoire du volume Macintosh HD monté à partir du
dev node du
jhfs+ --> le
dev node n'est
pas traversé pour un accès à sa condition de montage : les
headers du système de fichiers
jhfs+.
----------
j'aurais aimé savoir quelle est la taille minimale de la partition à créer pour accueillir High Sierra.
Je te conseille carrément
80 Go pour être à l'aise > ce qui laisse quand même
117 Go d'espace libre pour
Macintosh HD ! Car tu pourrais avoir envie d'installer des applications spécifiques dans
High Sierra et de toute façon il faut de la marge dans un volume. Admis que le Système va prendre dans les
30 Go > tu peux trouver que
50 Go de marge c'est beaucoup voire trop. Soit ! Mais si tu considères qu'une marge de
20 Go de libre est nécessaire > il convient que tu raisonnes à partir d'un plancher de taille de
50 Go.
----------
Désolé si ces questions paraissent absurdes
Les « questions » ne sont jamais absurdes > car la seule chose qui fasse « sens » pour l'entendement --> c'est la compréhension « théorique » des choses. Les solutions « pratiques », bien sûr, libèrent un espace d'opérations pour l'action, mais au prix de l'abandon du questionnement et d'un enfoncement dans l'exécution. Paul Valéry aimait exercer son esprit à des contemplations théoriques en début de journée > disant que, par là, il « achetait le droit d'être bête pour le restant de la journée ».
).
