Chemin d'invisible pas visible = Private

[FrançoisMacG]

Je suis en 10.4.11, et j'ai décidé de mettre à jour XCode et InterfaceBuilder.
Mon iBook et son clone étaient en 241 et 254 : la mise en œuvre de Developer Tools.pkg de XCode 2.5 les a fait passer en 25 et 256.

La réparation des autorisations juste avant la mise à jour était clean.
Après la mise à jour, j'aboutis à :

Réparation des autorisations pour “Macintosh HD”
Détermination des autorisations d'accès correctes.
Le groupe est différent sur ./Private, il devrait être 80 au lieu de 0
Autorisations d'accès différentes sur ./Private, elles devraient être drwxrwxr-x au lieu de drwxr-xr-x
Propriétaire et Groupe corrigés sur ./Private
Autorisations corrigées sur ./Private
Le groupe est différent sur ./private, il devrait être 0 au lieu de 80
Autorisations d'accès différentes sur ./private, elles devraient être drwxr-xr-x au lieu de drwxrwxr-x
Propriétaire et Groupe corrigés sur ./private
Autorisations corrigées sur ./private

Réparation des autorisations terminée
Les autorisations d'accès ont été vérifiées ou réparées sur le volume sélectionné

En affichant les fichiers invisibles avec Onyx, je trouve bien un dossier .private à la racine de HD, qui contient etc-tmp-var-tfpboot, et où moi-groupewheel-autres sont en lecture seule.
Le seul dossier Private que je trouve est dans HD>Developer et n'est pas invisible : il contient jam-pbhelpindexloader, et moi-groupe Admin y sont en lecture et écriture.

J'ai réparé le disque avec le clone (sans anomalie) puis DiskWarrior : la réparation des autorisations aboutit toujours au même message.
J'ai réparé les autorisations de mon HD à partir du clone : ça m'a corrigé deux autres anomalies :

Réparation des autorisations pour “Macintosh HD”
Détermination des autorisations d'accès correctes.
Le groupe est différent sur ./Private, il devrait être 80 au lieu de 0
Autorisations d'accès différentes sur ./Private, elles devraient être drwxrwxr-x au lieu de drwxr-xr-x
Propriétaire et Groupe corrigés sur ./Private
Autorisations corrigées sur ./Private
Autorisations d'accès différentes sur ./System/Library/User Template, elles devraient être drwxr-xr-x au lieu de drwx------
Propriétaire et Groupe corrigés sur ./System/Library/User Template
Autorisations corrigées sur ./System/Library/User Template
Le groupe est différent sur ./private, il devrait être 0 au lieu de 80
Autorisations d'accès différentes sur ./private, elles devraient être drwxr-xr-x au lieu de drwxrwxr-x
Propriétaire et Groupe corrigés sur ./private
Autorisations corrigées sur ./private
Autorisations d'accès différentes sur ./usr/libexec/dumpemacs, elles devraient être -r-xr-xr-x au lieu de -r-sr-xr-x
Propriétaire et Groupe corrigés sur ./usr/libexec/dumpemacs
Autorisations corrigées sur ./usr/libexec/dumpemacs

Réparation des autorisations terminée
Les autorisations d'accès ont été vérifiées ou réparées sur le volume sélectionné

mais elles ont été remises à l'envers en corrigeant de nouveau les autorisations à partir de HD.

Mon Mac semble fonctionner correctement, et l'anomalie des Autorisations ne me semble pour l'instant qu'intrigante (comment Utilitaire de Disque peut-il réparer les autorisations d'un dossier qui n'existe apparemment pas ?), mais cela m'inquiète vaguement.


La seule bourde que j'ai faite est de déplacer ADL Reference Library(878 Mo) et SDKs(343 Mo) de HD>Developer vers mon DDE : les transferts Cmd-glisser déposer se sont bien passés, sauf que j'ai dû corbelliser a mano les dossiers vides qui restaient dans HD>Developer après transfert (après coup, je me dis que j'aurais dû les corbelliser d'abord, et les transférer ensuite).
La réinstallation de Developer pourrait-elle corriger mon anomalie ? (dans l'hypothèse d'un fichier bom vérolé dans les Receipts)

 

[FrançoisMacG]

J'ai trouvé la solution.

Une discussion Apple faisait remarquer qu'il ne pouvait y avoir qu'un seul dossier "private" dans un Système non formaté sensible à la casse : private et Private ne pouvaient donc être qu'un même dossier, et je n'avais aucune chance de trouver ./Private !

C'est une autre discussion qui m'a donné la solution : déplacer le Receipt DeveloperTools.pkg hors du dossier Receipts (je l'ai quand même mis de côté, si jamais un jour Apple sortait une nouvelle mise à jour pour les DevTools...).

Et, dans l'Utilitaire de Disque de mon HD, le résultat a été immédiatement :

Réparation des autorisations pour “Macintosh HD”
Détermination des autorisations d'accès correctes.

Réparation des autorisations terminée
Les autorisations d'accès ont été vérifiées ou réparées sur le volume sélectionné

= il n'y a même pas eu de réparation !?

(j'ai ouvert Archive.bom dans le pkg avec TextEdit = j'ai refermé tout de suite, c'est impraticable pour moi ...)

 

[FrançoisMacG]

(j'ai ouvert Archive.bom dans le pkg avec TextEdit = j'ai refermé tout de suite, c'est impraticable pour moi ...)

J'ai fini par ouvrir l'Archive.bom du Receipt DeveloperTools.pkg foireux avec le Terminal de mon 10.4 (= lsbom ; en 10.5, il faut plutôt passer par pkgutil) :

j'ai trouvé trois fichiers qui commençaient par ./Private (avec un P majuscule) et aucun private
= mauvaise rédaction d'Apple, donc.

 

[Ana Lara]

J'aimerai bien à mon tour t' aider mais

 

[bompi]

En fait, je ne vois pas bien quel est le problème :rateau:

 

[FrançoisMacG]

En fait, je ne vois pas bien quel est le problème :rateau:

Il n'y a plus de problème.

Il y avait un bug, que j'ai mis du temps à isoler,
et j'ai raconté ma mésaventure pour éviter bien des errements à d'autres qui pourraient la subir eux aussi : quand on ne trouve pas, on s'énerve, et quand on s'énerve, on finit par faire une bourde.

Mais je crois que tu l'avais compris...