Voilà ce que je viens de constater au sujet des associations entre
applications et fichiers... ce fameux launchservices qui nous prend la
tête depuis quelques jours.
2 fichiers semblent concernés par ces associations :
- le fichier .csstore créé par le système dans un sous-sous-dossier
(nommé "0") du dossier /var/folders
Ce fichier semble plutôt "générique" : il est créé par le système en
fonction des applis qu'il trouve sur l'ordi et fait des associations
appli/fichier disons : standard.
- le 2ème fichier est plus spécifique à l'utilisateur : c'est le fichier
com.apple.launchservices.secure.plist situé dans le dossier
/Users/MV/Library/Preferences/com.apple.LaunchServices
C'est ce fichier qui semble battre de l'aile chez certains...
J'ai, par exemple, demandé à ce que tous les fichiers .txt créés avec
TextEdit soient ouverts avec BBEdit et je me suis aperçu qu'une nouvelle
clé apparaissait dans le fichier ci-dessus :
Mieux : j'ai édité ce fichier et j'ai modifié manuellement la ligne
<string>com.apple.textedit</string>
en :
<string>com.barebones.bbedit</string>
J'ai relancé le Finder et BBEdit est redevenu l'appli par défaut pour
les fichiers .txt
J'ai testé de la même manière avec les fichiers de type .plist et même
résultats probants que précédemment.
Donc les associations définies par l'utilisateur sont bien à chercher
dans ce fichier.
Si vous voulez qu'il ne bouge plus... verrouillez-le !
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
La modification (donc temporaire) par Firefox ou par l'utilisateur (comme je l'ai indiqué si on verrouille le fichier de préf) n'est pas forcément écrite en dur dans un quelconque fichier : elle peut simplement être en RAM... même si les apparences font penser qu'elle est écrite dans le fichier .csstore
J'aurais dû y penser plus tôt... J'ai verrouillé le fichier .csstore en plus du fichier .plist et... j'ai toujours la possibilité de modifier l'appli par défaut pour ouvrir mes fichiers .txt par exemple. Donc donc donc... ce n'est pas en modifiant le .csstore ni le .plist que le "bug" agit mais plus probablement en RAM !... -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
J'ai écrit :
La modification (donc temporaire) par Firefox ou par l'utilisateur
(comme je l'ai indiqué si on verrouille le fichier de préf) n'est pas
forcément écrite en dur dans un quelconque fichier : elle peut
simplement être en RAM... même si les apparences font penser qu'elle est
écrite dans le fichier .csstore
J'aurais dû y penser plus tôt...
J'ai verrouillé le fichier .csstore en plus du fichier .plist et... j'ai
toujours la possibilité de modifier l'appli par défaut pour ouvrir mes
fichiers .txt par exemple.
Donc donc donc... ce n'est pas en modifiant le .csstore ni le .plist que
le "bug" agit mais plus probablement en RAM !...
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
La modification (donc temporaire) par Firefox ou par l'utilisateur (comme je l'ai indiqué si on verrouille le fichier de préf) n'est pas forcément écrite en dur dans un quelconque fichier : elle peut simplement être en RAM... même si les apparences font penser qu'elle est écrite dans le fichier .csstore
J'aurais dû y penser plus tôt... J'ai verrouillé le fichier .csstore en plus du fichier .plist et... j'ai toujours la possibilité de modifier l'appli par défaut pour ouvrir mes fichiers .txt par exemple. Donc donc donc... ce n'est pas en modifiant le .csstore ni le .plist que le "bug" agit mais plus probablement en RAM !... -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
josephb
suivi vers fcsm MV a transcrit dans deux posts ses expériences remarquables :
Ce que je trouve anormal de mon côté, c'est qu'il soit possible de passer outre (même temporairement) aux préférences définies par l'utilisateur et recensées dans le fichier com.apple.launchservices.secure.plist J'ai verrouillé le fichier .csstore en plus du fichier .plist et... j'ai toujours la possibilité de modifier l'appli par défaut pour ouvrir mes fichiers .txt par exemple. Donc donc donc... ce n'est pas en modifiant le .csstore ni le .plist que le "bug" agit mais plus probablement en RAM !...
Je salue tes éclairantes recherches dans toutes les directions qui semblent accessibles, mais en déduire que les prefs utilisateurs seraient quelque part en… en RAM ?? Je ne le pense pas, je verrais une gestion dynamique et temps réel via un SGBD, plus probablement. Toutes précautions oratoires posées, je pense que l'on est confronté à l'évolution structurelle profonde de macOS depuis Yosemite principalement. Convergence vers iOS oblige : un nouveau paradigme de contrôle et gestion des paramètres utilisateur a été installé dans macOS, faisant appel intensivement à un réseau de SGBD à la fois vertical et transversal. Le "file System" et l'application "Finder" semblent être particulièrement concernés par cette nouvelle forme de gestion. Ses compétences surpassent maintenant celles de l'ancienne architecture dont les .plist et .csstore étaient des piliers et sont toujours là parce que c'est Unix et qu'on ne peut en faire table rase d'un seul coup. Le fait qu'on y ait aucun accès, très peu d'informations autres que rumeurs, entretient frustration et spéculations, et c'est dommage qu'Apple ne communique pas un peu sur ses intentions et méthodes en la matière. Pour l'instant et globalement cette cohabitation de méthodes de gestion de l'OS se passe moins mal qu'on pourrait le craindre, même si les performances du Système semblent en pâtir et si des bugs aléatoires et agaçants (dont celui objet de ce fil) semblent bien résister et alimenter les discussions sur pas mal de forums. Quant à savoir si le futur de ce maciOS en devenir saura séduire les "macounets" crispés, c'est un autre débat ;-) Cordialement, -- J. B.
suivi vers fcsm
MV <mv@orange.invalid> a transcrit dans deux posts ses expériences
remarquables :
Ce que je trouve anormal de mon côté, c'est qu'il soit possible de
passer outre (même temporairement) aux préférences définies par
l'utilisateur et recensées dans le fichier
com.apple.launchservices.secure.plist
J'ai verrouillé le fichier .csstore en plus du fichier .plist et... j'ai
toujours la possibilité de modifier l'appli par défaut pour ouvrir mes
fichiers .txt par exemple.
Donc donc donc... ce n'est pas en modifiant le .csstore ni le .plist que
le "bug" agit mais plus probablement en RAM !...
Je salue tes éclairantes recherches dans toutes les directions qui
semblent accessibles, mais en déduire que les prefs utilisateurs
seraient quelque part en… en RAM ??
Je ne le pense pas, je verrais une gestion dynamique et temps réel via
un SGBD, plus probablement.
Toutes précautions oratoires posées, je pense que l'on est confronté à
l'évolution structurelle profonde de macOS depuis Yosemite
principalement.
Convergence vers iOS oblige : un nouveau paradigme de contrôle et
gestion des paramètres utilisateur a été installé dans macOS, faisant
appel intensivement à un réseau de SGBD à la fois vertical et
transversal.
Le "file System" et l'application "Finder" semblent être
particulièrement concernés par cette nouvelle forme de gestion.
Ses compétences surpassent maintenant celles de l'ancienne architecture
dont les .plist et .csstore étaient des piliers et sont toujours là
parce que c'est Unix et qu'on ne peut en faire table rase d'un seul
coup.
Le fait qu'on y ait aucun accès, très peu d'informations autres que
rumeurs, entretient frustration et spéculations, et c'est dommage
qu'Apple ne communique pas un peu sur ses intentions et méthodes en la
matière.
Pour l'instant et globalement cette cohabitation de méthodes de gestion
de l'OS se passe moins mal qu'on pourrait le craindre, même si les
performances du Système semblent en pâtir et si des bugs aléatoires et
agaçants (dont celui objet de ce fil) semblent bien résister et
alimenter les discussions sur pas mal de forums.
Quant à savoir si le futur de ce maciOS en devenir saura séduire les
"macounets" crispés, c'est un autre débat ;-)
suivi vers fcsm MV a transcrit dans deux posts ses expériences remarquables :
Ce que je trouve anormal de mon côté, c'est qu'il soit possible de passer outre (même temporairement) aux préférences définies par l'utilisateur et recensées dans le fichier com.apple.launchservices.secure.plist J'ai verrouillé le fichier .csstore en plus du fichier .plist et... j'ai toujours la possibilité de modifier l'appli par défaut pour ouvrir mes fichiers .txt par exemple. Donc donc donc... ce n'est pas en modifiant le .csstore ni le .plist que le "bug" agit mais plus probablement en RAM !...
Je salue tes éclairantes recherches dans toutes les directions qui semblent accessibles, mais en déduire que les prefs utilisateurs seraient quelque part en… en RAM ?? Je ne le pense pas, je verrais une gestion dynamique et temps réel via un SGBD, plus probablement. Toutes précautions oratoires posées, je pense que l'on est confronté à l'évolution structurelle profonde de macOS depuis Yosemite principalement. Convergence vers iOS oblige : un nouveau paradigme de contrôle et gestion des paramètres utilisateur a été installé dans macOS, faisant appel intensivement à un réseau de SGBD à la fois vertical et transversal. Le "file System" et l'application "Finder" semblent être particulièrement concernés par cette nouvelle forme de gestion. Ses compétences surpassent maintenant celles de l'ancienne architecture dont les .plist et .csstore étaient des piliers et sont toujours là parce que c'est Unix et qu'on ne peut en faire table rase d'un seul coup. Le fait qu'on y ait aucun accès, très peu d'informations autres que rumeurs, entretient frustration et spéculations, et c'est dommage qu'Apple ne communique pas un peu sur ses intentions et méthodes en la matière. Pour l'instant et globalement cette cohabitation de méthodes de gestion de l'OS se passe moins mal qu'on pourrait le craindre, même si les performances du Système semblent en pâtir et si des bugs aléatoires et agaçants (dont celui objet de ce fil) semblent bien résister et alimenter les discussions sur pas mal de forums. Quant à savoir si le futur de ce maciOS en devenir saura séduire les "macounets" crispés, c'est un autre débat ;-) Cordialement, -- J. B.
mv
Je reste dans fcomox avec ta permission (et même sans d'ailleurs ! ) car discuter de l'évolution de macOS me passe par-dessus la tête... Non pas que je n'aie pas d'opinion mais en discuter ne m'intéresse pas vraiment... Joseph-B wrote:
Je salue tes éclairantes recherches dans toutes les directions qui semblent accessibles, mais en déduire que les prefs utilisateurs seraient quelque part en… en RAM ??
Je me suis sans doute mal exprimé car ce n'est pas exactement ce que je voulais dire... Alors je reprends pour développer ma vision des choses : alors que j'ai verrouillé les deux fichiers qui semblent au coeur du service de lancement des applis, j'ai la possibilité (temporaire... j'insiste... ) de modifier la liaison appli/fichier. Ne pouvant écrire dans aucun des 2 fichiers (1), il faut bien que ce soit écrit quelque part et de *façon volatile* puisque le redémarrage annule la modification préalablement faite... d'où l'idée que j'ai émise d'une mise provisoire en RAM *à défaut de pouvoir écrire dans les 2 fichiers*. Si c'était dans une base de données, se pourrait-il aussi que l'info enregistrée soit effacée au redémarrage ? Mon idée est-elle à ce point absurde ? De toute manière, que ce soit dans une base de données inaccessible au quidam ou en RAM, le résultat est le même : fait chier ! ;-) (1) Pour ce qui est écrit dans le fichier .csstore, j'y reviens dans la réponse que je vais faire à Benoit après l'envoi de ce message. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Je reste dans fcomox avec ta permission (et même sans d'ailleurs ! ) car
discuter de l'évolution de macOS me passe par-dessus la tête... Non pas
que je n'aie pas d'opinion mais en discuter ne m'intéresse pas
vraiment...
Joseph-B <josephb@nowhere.invalid> wrote:
Je salue tes éclairantes recherches dans toutes les directions qui
semblent accessibles, mais en déduire que les prefs utilisateurs
seraient quelque part en… en RAM ??
Je me suis sans doute mal exprimé car ce n'est pas exactement ce que je
voulais dire...
Alors je reprends pour développer ma vision des choses : alors que j'ai
verrouillé les deux fichiers qui semblent au coeur du service de
lancement des applis, j'ai la possibilité (temporaire... j'insiste... )
de modifier la liaison appli/fichier.
Ne pouvant écrire dans aucun des 2 fichiers (1), il faut bien que ce
soit écrit quelque part et de *façon volatile* puisque le redémarrage
annule la modification préalablement faite... d'où l'idée que j'ai émise
d'une mise provisoire en RAM *à défaut de pouvoir écrire dans les 2
fichiers*.
Si c'était dans une base de données, se pourrait-il aussi que l'info
enregistrée soit effacée au redémarrage ?
Mon idée est-elle à ce point absurde ?
De toute manière, que ce soit dans une base de données inaccessible au
quidam ou en RAM, le résultat est le même : fait chier ! ;-)
(1) Pour ce qui est écrit dans le fichier .csstore, j'y reviens dans la
réponse que je vais faire à Benoit après l'envoi de ce message.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Je reste dans fcomox avec ta permission (et même sans d'ailleurs ! ) car discuter de l'évolution de macOS me passe par-dessus la tête... Non pas que je n'aie pas d'opinion mais en discuter ne m'intéresse pas vraiment... Joseph-B wrote:
Je salue tes éclairantes recherches dans toutes les directions qui semblent accessibles, mais en déduire que les prefs utilisateurs seraient quelque part en… en RAM ??
Je me suis sans doute mal exprimé car ce n'est pas exactement ce que je voulais dire... Alors je reprends pour développer ma vision des choses : alors que j'ai verrouillé les deux fichiers qui semblent au coeur du service de lancement des applis, j'ai la possibilité (temporaire... j'insiste... ) de modifier la liaison appli/fichier. Ne pouvant écrire dans aucun des 2 fichiers (1), il faut bien que ce soit écrit quelque part et de *façon volatile* puisque le redémarrage annule la modification préalablement faite... d'où l'idée que j'ai émise d'une mise provisoire en RAM *à défaut de pouvoir écrire dans les 2 fichiers*. Si c'était dans une base de données, se pourrait-il aussi que l'info enregistrée soit effacée au redémarrage ? Mon idée est-elle à ce point absurde ? De toute manière, que ce soit dans une base de données inaccessible au quidam ou en RAM, le résultat est le même : fait chier ! ;-) (1) Pour ce qui est écrit dans le fichier .csstore, j'y reviens dans la réponse que je vais faire à Benoit après l'envoi de ce message. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
josephb
MV wrote:
Ne pouvant écrire dans aucun des 2 fichiers (1), il faut bien que ce soit écrit quelque part et de *façon volatile* puisque le redémarrage annule la modification préalablement faite... d'où l'idée que j'ai émise d'une mise provisoire en RAM *à défaut de pouvoir écrire dans les 2 fichiers*. Si c'était dans une base de données, se pourrait-il aussi que l'info enregistrée soit effacée au redémarrage ?
Il n'est absolument pas incompatible (au contraire) qu'un SGBD régénère des enregistrements (au sens SGDB du mot) lors de l'ouverture d'un fichier de base, car plusieurs niveaux d'enregistrements scrutés par des algorithmes de compatibilité multi-critères peuvent être mis en action. La "robustesse" de la base en passe par là. Je t'ai raconté en privé les expériences folles auxquelles je me suis livré entre juillet et septembre et qui ont amené à la "destruction fonctionnelle" du triptyque Spotlight, Time Machine et Finder avec finalement l'obligation de reformater le DD et tout réinstaller depuis un clone. J'en ai tiré la conviction qu'il existait une couche de contrôle, de type SGBD, supplémentaire, plus profonde, et prioritaire sur celle que l'on peut voir grâce aux .plist et autres fichiers de préférences. Mais je ne peux en apporter la preuve formelle.
Mon idée est-elle à ce point absurde ?
Je dirais peu compatible avec la philosophie Unix où tout est consigné en dur ou au moins mis en cache écrit sur disque. Tu me diras qu'un cache ou un tmp effacé au redémarrage, ça équivaut à de la RAM, je te l'accorde.
De toute manière, que ce soit dans une base de données inaccessible au quidam ou en RAM, le résultat est le même : fait chier ! ;-)
Ben oui, on n'est pas sensés, à notre niveau, aller interpéter les entrailes du poulet, on doit rester admirer ce qu'il nous est donné à voir, rien de plus ;-) -- J. B.
MV <mv@orange.invalid> wrote:
Ne pouvant écrire dans aucun des 2 fichiers (1), il faut bien que ce
soit écrit quelque part et de *façon volatile* puisque le redémarrage
annule la modification préalablement faite... d'où l'idée que j'ai émise
d'une mise provisoire en RAM *à défaut de pouvoir écrire dans les 2
fichiers*.
Si c'était dans une base de données, se pourrait-il aussi que l'info
enregistrée soit effacée au redémarrage ?
Il n'est absolument pas incompatible (au contraire) qu'un SGBD régénère
des enregistrements (au sens SGDB du mot) lors de l'ouverture d'un
fichier de base, car plusieurs niveaux d'enregistrements scrutés par des
algorithmes de compatibilité multi-critères peuvent être mis en action.
La "robustesse" de la base en passe par là.
Je t'ai raconté en privé les expériences folles auxquelles je me suis
livré entre juillet et septembre et qui ont amené à la "destruction
fonctionnelle" du triptyque Spotlight, Time Machine et Finder avec
finalement l'obligation de reformater le DD et tout réinstaller depuis
un clone.
J'en ai tiré la conviction qu'il existait une couche de contrôle, de
type SGBD, supplémentaire, plus profonde, et prioritaire sur celle que
l'on peut voir grâce aux .plist et autres fichiers de préférences.
Mais je ne peux en apporter la preuve formelle.
Mon idée est-elle à ce point absurde ?
Je dirais peu compatible avec la philosophie Unix où tout est consigné
en dur ou au moins mis en cache écrit sur disque.
Tu me diras qu'un cache ou un tmp effacé au redémarrage, ça équivaut à
de la RAM, je te l'accorde.
De toute manière, que ce soit dans une base de données inaccessible au
quidam ou en RAM, le résultat est le même : fait chier ! ;-)
Ben oui, on n'est pas sensés, à notre niveau, aller interpéter les
entrailes du poulet, on doit rester admirer ce qu'il nous est donné à
voir, rien de plus ;-)
Ne pouvant écrire dans aucun des 2 fichiers (1), il faut bien que ce soit écrit quelque part et de *façon volatile* puisque le redémarrage annule la modification préalablement faite... d'où l'idée que j'ai émise d'une mise provisoire en RAM *à défaut de pouvoir écrire dans les 2 fichiers*. Si c'était dans une base de données, se pourrait-il aussi que l'info enregistrée soit effacée au redémarrage ?
Il n'est absolument pas incompatible (au contraire) qu'un SGBD régénère des enregistrements (au sens SGDB du mot) lors de l'ouverture d'un fichier de base, car plusieurs niveaux d'enregistrements scrutés par des algorithmes de compatibilité multi-critères peuvent être mis en action. La "robustesse" de la base en passe par là. Je t'ai raconté en privé les expériences folles auxquelles je me suis livré entre juillet et septembre et qui ont amené à la "destruction fonctionnelle" du triptyque Spotlight, Time Machine et Finder avec finalement l'obligation de reformater le DD et tout réinstaller depuis un clone. J'en ai tiré la conviction qu'il existait une couche de contrôle, de type SGBD, supplémentaire, plus profonde, et prioritaire sur celle que l'on peut voir grâce aux .plist et autres fichiers de préférences. Mais je ne peux en apporter la preuve formelle.
Mon idée est-elle à ce point absurde ?
Je dirais peu compatible avec la philosophie Unix où tout est consigné en dur ou au moins mis en cache écrit sur disque. Tu me diras qu'un cache ou un tmp effacé au redémarrage, ça équivaut à de la RAM, je te l'accorde.
De toute manière, que ce soit dans une base de données inaccessible au quidam ou en RAM, le résultat est le même : fait chier ! ;-)
Ben oui, on n'est pas sensés, à notre niveau, aller interpéter les entrailes du poulet, on doit rester admirer ce qu'il nous est donné à voir, rien de plus ;-) -- J. B.
mv
Joseph-B a soumis à notre sagacité :
Mon idée est-elle à ce point absurde ?
Je dirais peu compatible avec la philosophie Unix où tout est consigné en dur ou au moins mis en cache écrit sur disque.
Si cette base en dehors des .csstore existe, pourquoi ce .csstore dans le dossier /var/folders/zz/.... ? Si je te dis que c'est ça la base de données *générique* sur laquelle sont ensuite construites les bases pour chaque utilisateur, tu en penses quoi ? Que ça peut être simplement la copie d'une autre base située ailleurs ? Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Joseph-B <josephb@nowhere.invalid> a soumis à notre sagacité :
> Mon idée est-elle à ce point absurde ?
Je dirais peu compatible avec la philosophie Unix où tout est consigné
en dur ou au moins mis en cache écrit sur disque.
Si cette base en dehors des .csstore existe, pourquoi ce .csstore dans
le dossier /var/folders/zz/.... ? Si je te dis que c'est ça la base de
données *générique* sur laquelle sont ensuite construites les bases pour
chaque utilisateur, tu en penses quoi ? Que ça peut être simplement la
copie d'une autre base située ailleurs ?
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Je dirais peu compatible avec la philosophie Unix où tout est consigné en dur ou au moins mis en cache écrit sur disque.
Si cette base en dehors des .csstore existe, pourquoi ce .csstore dans le dossier /var/folders/zz/.... ? Si je te dis que c'est ça la base de données *générique* sur laquelle sont ensuite construites les bases pour chaque utilisateur, tu en penses quoi ? Que ça peut être simplement la copie d'une autre base située ailleurs ? Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
mv
Eckard a soumis à notre sagacité :
Si ça t'intéresse encore
Si je te disais non, tu me croirais ? <https://forums.macrumors.com/threads/something-keeps-changing-my-open-with-defaults.2103071/> Rien de bien bien intéressant... Il me semble qu'on a été un peu plus loin ici, non ? Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Eckard <eckard@invalid.fr> a soumis à notre sagacité :
Rien de bien bien intéressant... Il me semble qu'on a été un peu plus
loin ici, non ?
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Si je te disais non, tu me croirais ? <https://forums.macrumors.com/threads/something-keeps-changing-my-open-with-defaults.2103071/> Rien de bien bien intéressant... Il me semble qu'on a été un peu plus loin ici, non ? Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
mv
Eckard a soumis à notre sagacité :
Si ça t'intéresse encore
Une précision en passant, à toute fin utile : OnyX ou la commande dans le Terminal que je t'avais indiquée font tous les 2 la même chose : ils détruisent le fichier .csstore de l'utilisateur (et ne touchent pas aux autres .csstore), fichier qui se reconstruit tout seul comme un grand (soit par relance du Finder soit par réouverture de la session soit par redémarrage) et laissent intact le fichier .plist du dossier des préférences. Donc le virer à la main revient exactement au même ! Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Eckard <eckard@invalid.fr> a soumis à notre sagacité :
Si ça t'intéresse encore
Une précision en passant, à toute fin utile : OnyX ou la commande dans
le Terminal que je t'avais indiquée font tous les 2 la même chose : ils
détruisent le fichier .csstore de l'utilisateur (et ne touchent pas aux
autres .csstore), fichier qui se reconstruit tout seul comme un grand
(soit par relance du Finder soit par réouverture de la session soit par
redémarrage) et laissent intact le fichier .plist du dossier des
préférences.
Donc le virer à la main revient exactement au même !
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
Une précision en passant, à toute fin utile : OnyX ou la commande dans le Terminal que je t'avais indiquée font tous les 2 la même chose : ils détruisent le fichier .csstore de l'utilisateur (et ne touchent pas aux autres .csstore), fichier qui se reconstruit tout seul comme un grand (soit par relance du Finder soit par réouverture de la session soit par redémarrage) et laissent intact le fichier .plist du dossier des préférences. Donc le virer à la main revient exactement au même ! Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
josephb
MV wrote:
Si je te dis que c'est ça la base de données *générique* sur laquelle sont ensuite construites les bases pour chaque utilisateur, tu en penses quoi ?
Si base de donnée générique il y a, je la vois bien dans un de ces dossiers affectés d'un sens interdit. Et il ne s'agit probablement pas de 1 base de données, mais tout un montage de bases dédiées à diverses propriétés et tâches sous contrôle d'un SGBD. .csstore est un fichier de cache du Système, je serais bien surpris qu'il soit lisible en tant que .psql par postgreSQL ; autant qu'un éditeur de texte permette d'en juger, je ne lui vois pas une structure de base de données.
Que ça peut être simplement la copie d'une autre base située ailleurs ?
Je pencherai plutôt pour ça, ce .csstore ressemble tellement à une version décharge publique des .plist des bundle d'application, que je le vois mal jouer un rôle actif direct dans les interactions Système. Ce serait un gâchis de temps et ressources invraisemblable qu'il faille "parser" un tel fichier à chaque fois que le Système voudrait en extraire une propriété (association ou autre). En plus le laisser dans un dossier accessible aux curieux ? J'imaine que c'est un "repository", en cache, auquel le système peut faire appel au cas où un des bases dédiées viendrait à être corrompue. Ce qui collerait avec le fait qu'il soit mis à jour au moindre changement, qu'il soit reconstitué à l'identique en cas d'effacement, mais qu'il ne soit pas indispensable (verrouillage) à la bonne marche du Système. Mais j'imagine peut-être à côté de la plaque, hein ;-) -- J. B.
MV <mv@orange.invalid> wrote:
Si je te dis que c'est ça la base de
données *générique* sur laquelle sont ensuite construites les bases pour
chaque utilisateur, tu en penses quoi ?
Si base de donnée générique il y a, je la vois bien dans un de ces
dossiers affectés d'un sens interdit.
Et il ne s'agit probablement pas de 1 base de données, mais tout un
montage de bases dédiées à diverses propriétés et tâches sous contrôle
d'un SGBD.
.csstore est un fichier de cache du Système, je serais bien surpris
qu'il soit lisible en tant que .psql par postgreSQL ; autant qu'un
éditeur de texte permette d'en juger, je ne lui vois pas une structure
de base de données.
Que ça peut être simplement la
copie d'une autre base située ailleurs ?
Je pencherai plutôt pour ça, ce .csstore ressemble tellement à une
version décharge publique des .plist des bundle d'application, que je le
vois mal jouer un rôle actif direct dans les interactions Système.
Ce serait un gâchis de temps et ressources invraisemblable qu'il faille
"parser" un tel fichier à chaque fois que le Système voudrait en
extraire une propriété (association ou autre).
En plus le laisser dans un dossier accessible aux curieux ?
J'imaine que c'est un "repository", en cache, auquel le système peut
faire appel au cas où un des bases dédiées viendrait à être corrompue.
Ce qui collerait avec le fait qu'il soit mis à jour au moindre
changement, qu'il soit reconstitué à l'identique en cas d'effacement,
mais qu'il ne soit pas indispensable (verrouillage) à la bonne marche du
Système.
Mais j'imagine peut-être à côté de la plaque, hein ;-)
Si je te dis que c'est ça la base de données *générique* sur laquelle sont ensuite construites les bases pour chaque utilisateur, tu en penses quoi ?
Si base de donnée générique il y a, je la vois bien dans un de ces dossiers affectés d'un sens interdit. Et il ne s'agit probablement pas de 1 base de données, mais tout un montage de bases dédiées à diverses propriétés et tâches sous contrôle d'un SGBD. .csstore est un fichier de cache du Système, je serais bien surpris qu'il soit lisible en tant que .psql par postgreSQL ; autant qu'un éditeur de texte permette d'en juger, je ne lui vois pas une structure de base de données.
Que ça peut être simplement la copie d'une autre base située ailleurs ?
Je pencherai plutôt pour ça, ce .csstore ressemble tellement à une version décharge publique des .plist des bundle d'application, que je le vois mal jouer un rôle actif direct dans les interactions Système. Ce serait un gâchis de temps et ressources invraisemblable qu'il faille "parser" un tel fichier à chaque fois que le Système voudrait en extraire une propriété (association ou autre). En plus le laisser dans un dossier accessible aux curieux ? J'imaine que c'est un "repository", en cache, auquel le système peut faire appel au cas où un des bases dédiées viendrait à être corrompue. Ce qui collerait avec le fait qu'il soit mis à jour au moindre changement, qu'il soit reconstitué à l'identique en cas d'effacement, mais qu'il ne soit pas indispensable (verrouillage) à la bonne marche du Système. Mais j'imagine peut-être à côté de la plaque, hein ;-) -- J. B.
Eckard
Le 28/03/2018 à 23:35, MV a écrit :
Donc le virer à la main revient exactement au même ! Cordialement.
J'avais compris, merci !
Le 28/03/2018 à 23:35, MV a écrit :
Donc le virer à la main revient exactement au même !
Donc le virer à la main revient exactement au même ! Cordialement.
J'avais compris, merci !
mv
Joseph-B a soumis à notre sagacité :
En plus le laisser dans un dossier accessible aux curieux ?
Je crois que tu parles maintenant du .csstore de l'utilisateur et non plus du .csstore situé dans les fins fonds du dossier /var/folders/zz Avant que je benne tout le contenu du dossier /folders/ la semaine dernière, celui dont je parle était dans un dossier interdit justement.
J'imaine que c'est un "repository", en cache, auquel le système peut faire appel au cas où un des bases dédiées viendrait à être corrompue. Ce qui collerait avec le fait qu'il soit mis à jour au moindre changement, qu'il soit reconstitué à l'identique en cas d'effacement, mais qu'il ne soit pas indispensable (verrouillage) à la bonne marche du Système.
Je ne parlais pas du .csstore de l'utilisateur. Celui du dossier "zz" n'est que rarement mis à jour justement. Un truc que j'ai remarqué et dont j'ai oublié de rendre compte : j'ai défini OpenOffice pour ouvrir les fichiers MS Office. Si je poubellise le fichier .plist de mon dossier des préférences, l'association subsiste (normal car c'est écrit dans mon .csstore perso). Si je modifie ensuite les associations fichier/appli, par exemple en demandant la lecture des .jpg par Safari, le .plist est recréé et dedans figurent également mes autres préfs de liaison dont celles concernant OpenOffice... À croire que ce .plist joue le jeu d'une sauvegarde des préfs de l'utilisateur puisqu'il n'est pas touché par une reconstruction du LaunchServices (par OnyX ou via le Terminal). Bonne journée. Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
Joseph-B <josephb@nowhere.invalid> a soumis à notre sagacité :
En plus le laisser dans un dossier accessible aux curieux ?
Je crois que tu parles maintenant du .csstore de l'utilisateur et non
plus du .csstore situé dans les fins fonds du dossier /var/folders/zz
Avant que je benne tout le contenu du dossier /folders/ la semaine
dernière, celui dont je parle était dans un dossier interdit justement.
J'imaine que c'est un "repository", en cache, auquel le système peut
faire appel au cas où un des bases dédiées viendrait à être corrompue.
Ce qui collerait avec le fait qu'il soit mis à jour au moindre
changement, qu'il soit reconstitué à l'identique en cas d'effacement,
mais qu'il ne soit pas indispensable (verrouillage) à la bonne marche du
Système.
Je ne parlais pas du .csstore de l'utilisateur. Celui du dossier "zz"
n'est que rarement mis à jour justement.
Un truc que j'ai remarqué et dont j'ai oublié de rendre compte : j'ai
défini OpenOffice pour ouvrir les fichiers MS Office. Si je poubellise
le fichier .plist de mon dossier des préférences, l'association subsiste
(normal car c'est écrit dans mon .csstore perso). Si je modifie ensuite
les associations fichier/appli, par exemple en demandant la lecture des
.jpg par Safari, le .plist est recréé et dedans figurent également mes
autres préfs de liaison dont celles concernant OpenOffice...
À croire que ce .plist joue le jeu d'une sauvegarde des préfs de
l'utilisateur puisqu'il n'est pas touché par une reconstruction du
LaunchServices (par OnyX ou via le Terminal).
Bonne journée.
Cordialement.
--
Michel Vauquois - <http://michelvauquois.fr>
Nouveau : <http://art-doise-4.michelvauquois.free-h.fr>
et <http://art-doise-5.michelvauquois.free-h.fr>
En plus le laisser dans un dossier accessible aux curieux ?
Je crois que tu parles maintenant du .csstore de l'utilisateur et non plus du .csstore situé dans les fins fonds du dossier /var/folders/zz Avant que je benne tout le contenu du dossier /folders/ la semaine dernière, celui dont je parle était dans un dossier interdit justement.
J'imaine que c'est un "repository", en cache, auquel le système peut faire appel au cas où un des bases dédiées viendrait à être corrompue. Ce qui collerait avec le fait qu'il soit mis à jour au moindre changement, qu'il soit reconstitué à l'identique en cas d'effacement, mais qu'il ne soit pas indispensable (verrouillage) à la bonne marche du Système.
Je ne parlais pas du .csstore de l'utilisateur. Celui du dossier "zz" n'est que rarement mis à jour justement. Un truc que j'ai remarqué et dont j'ai oublié de rendre compte : j'ai défini OpenOffice pour ouvrir les fichiers MS Office. Si je poubellise le fichier .plist de mon dossier des préférences, l'association subsiste (normal car c'est écrit dans mon .csstore perso). Si je modifie ensuite les associations fichier/appli, par exemple en demandant la lecture des .jpg par Safari, le .plist est recréé et dedans figurent également mes autres préfs de liaison dont celles concernant OpenOffice... À croire que ce .plist joue le jeu d'une sauvegarde des préfs de l'utilisateur puisqu'il n'est pas touché par une reconstruction du LaunchServices (par OnyX ou via le Terminal). Bonne journée. Cordialement. -- Michel Vauquois - <http://michelvauquois.fr> Nouveau : <http://art-doise-4.michelvauquois.free-h.fr> et <http://art-doise-5.michelvauquois.free-h.fr>
