Discussion :

[olibara]

Bonjour

Je viens de me battre pendant plusieurs heure en ne comprenant pas OU ma nouvelle installation de MySqlserver sour Window7 avait placé le repertoire Data

En effet le config spécifiait

#Path to the database root
datadir="C:/ProgramData/MySQL/MySQL Server 5.5/Data/"

Mais nulle trace de ce repertoire !
J'ai finalement compris Que Windows considerait qu'un utilisateur administrateur et proprietaire de sa machine n'avait pas la maturité et la sagesse sufisante pour acceder aux données qu'il confiait a Windows7

Je me suis donc empressé de creer un repertoire c:/MySqlData/ et d'adapter les settings de MySql pour y acceder

Mais je ne comprends toujours pas cette sequestration que Windows opere sur mes propres données !

En tout cas ca m'incite a rester XP le plus longtemps possible !

[Etre_Libre]

XP planquait déjà un paquet de dossiers...

Par contre, MySQL aurait pu vous laisser le choix du dossier, tout simplement

PS : tous ces dossiers sont visibles quand on affiche tous les dossiers cachés

[sevyc64]

J'ai finalement compris Que Windows considerait qu'un utilisateur administrateur et proprietaire de sa machine n'avait pas la maturité et la sagesse sufisante pour acceder aux données qu'il confiait a Windows7

Peut-être pas à tord justement.

Le compte de l'utilisateur habituel d'une machine ne devrait jamais être un compte avec des droits administrateur. Un compte administrateur devrait être uniquement réservé à administrer la machine, pas l'utiliser.

C'est pour cela que désormais, depuis Vista, un compte administrateur, a, en temps normal, pas plus de droits qu'un compte utilisateur.

Bien évidemment cette nouvelle règle met en lumière des logiciels bien mal écrit et depuis longtemps alors même que ces règles de sécurités sont recommandées depuis plusieurs années (WNT4/W2K). Mais jusqu'à, elles n'étaient pas vraiment vérifiées, alors les développeurs ont pris l'habitude de faire un peu n'importe quoi.

[olibara]

Bien évidemment cette nouvelle règle met en lumière des logiciels bien mal écrit et depuis longtemps alors même que ces règles de sécurités sont recommandées depuis plusieurs années (WNT4/W2K). Mais jusqu'à, elles n'étaient pas vraiment vérifiées, alors les développeurs ont pris l'habitude de faire un peu n'importe quoi.

De fait

Mais c'est quand meme troublant d'installer (avec son compte utilisateur+Admnistrateur) une application qui installe des données utilisateur dans un repertoire caché pour celui ci

[sevyc64]

Les données utilisateurs doivent être dans le répertoire utilisateur.

D'autres données propres au logiciel (et pas spécifique à l'utilisateur) peuvent être dans des répertoires cachés car elles ne sont pas censée être directement accessible à l'utilisateur.
Un besoin d'accéder à ces données pour un utilisateur peut venir d'une mauvaise conception du logiciel, ou d'une "mauvaise utilisation" voire d'une confusion entre les rôles utilisateur et administrateur.
Le problème est que pendant bien longtemps Windows a été beaucoup trop permissif avec ces règles de base, ce qui a eu pour effet que beaucoup d'utilisateurs ont pris de mauvaises habitudes.


Pour en revenir à MySQL, en tant qu'utilisateur, tu n'as normalement pas besoin d'accéder directement au contenu de répertoire Data, tu accède aux données qui y sont stockées à travers le moteur MySql.

Un administrateur pourra avoir besoin d'y accéder, pour, par exemple effectuer des backups. Dans ce cas, il est censé savoir ou et comment acceder à ce dossier, même s'il s'agit d'un dossier caché.

[olibara]

Merci sevyc64

Effectivement c'est pertinent
Mais déroutant quand on est pris par surprise !

Et quand on installe des chose dans un ouvel environnement on est agressé par beaucoup de surprises inatendues !

[shawn12]

Le répertoire Program Data est à la racine du disque mais est caché par défaut (afin d'éviter les mauvaises manip). Pour le voir apparaitre dans l'explorateur, il suffit d'activer l'affichage des fichiers cachés.

Il me semble qu'on peut y accéder en saisissant %programdata% dans la barre d'adresse de l'explorateur.

Sinon, je trouve personnellement que c'est une bonne chose de limiter l'écriture dans les répertoires tels que Windows ou Program Files. En effet, ce sont des répertoire sensibles, destinés aux programmes exécutables et non aux données. C'est l'une des raisons pour laquelle le répertoire Program Data a été introduit.

D'ailleurs, si un logiciel essaie d'écrire dans Program Files sans avoir les privilèges élevés, cette écriture sera virtualisée et se fera en réalité dans le répertoire VirtualStore.

[olibara]

Sinon, je trouve personnellement que c'est une bonne chose de limiter l'écriture dans les répertoires tels que Windows ou Program Files. En effet, ce sont des répertoire sensibles, destinés aux programmes exécutables et non aux données. C'est l'une des raisons pour laquelle le répertoire Program Data a été introduit.

D'ailleurs, si un logiciel essaie d'écrire dans Program Files sans avoir les privilèges élevés, cette écriture sera virtualisée et se fera en réalité dans le répertoire VirtualStore.

D'accord avec toi sur la séparation Program Files et ProgramData

- Au passage bonne nouvelle il n'y a plus de stupide espace comme dans Program Files

Par contre Program Files n'ayant jamais eté caché j'ai des doutes sur la pertinence de vouloir cacher programdata

[shawn12]

Ben, la protection de Program Files est assurée par les permissions. Les utilisateurs n'ont pas la possibilité d'y toucher puisqu'ils n'ont pas les droits.

Par contre pour ProgramData ils ont les droits d'écriture (normal, c'est fait pour) mais il vaut quand même pas qu'ils en profitent pour aller bricoler tout et n'importe quoi. Du coup, c'est un peu caché (attribut "caché") mais pas trop (n'a pas l'attribut "systèm").

Il faut se rappeler que Windows est utilisé par plusieurs dizaires de millions de personnes et que parmi elles il y en a beaucoup qui ne comprennent pas forcément tout ce qu'elles font avec le système. Ceci peut être génant pour la sécurité de l'ordinateur personnel mais aussi du réseau mondial (botnets)...