Outrepasser les droits d'écriture dans un répertoire (suite)
2 réponses
Bertrand Lenoir-Welter
> >> Ces fichiers devraient plutot être dans Documents and
> >> settings\All Users\Application Data\Ton appli.
> >
> > Malheureusement pas possible. L'appli peut être installée en
> > plusieurs endroits sous le même nom mais avec des paramètres
> > différents. Trop long à expliquer pourquoi, mais c'est comme
> > ça. Je peux pas centraliser les paramètres. Je dois les
> > enregistrer dans le même répertoire que l'appli.
> Ce que tu dis est incohérent : Si tu as besoin de plusieurs
> paramétrages différents, mettre un fichier .ini sous Program Files
> n'est pas une solution. Quelle que soit la solution que tu as
> utilisé dans Program Files pour avoir plusieurs .ini (plusieurs
> fichies, 1 fichier avec plusieurs entrées, etc...), tu n'as qu'à
> appliquer cette même solution dans Application Data.
Salut
Je reviens sur ce sujet, après avoir constaté que je suis effectivement
toujours en mode Admin et ne fais jamais de tests en mode User. J'ai
aussi fait un petit test juste pour voir : je recherche dans Program
Files tous les fichiers INI, avec tri par date. Résultat, rien que pour
des fichiers INI (j'en ai pas cherché d'autres) les applications sur mon
disque qui écrivent dans ces fichiers à chaque utilisation sont :
- AutoCad
- CDex MP3-Encoder
- CorelDraw 7
- CuteFTP
- Epson SmartPanel for Scanner
- Intervideo WinRip
- WinAmp
Il me semble que je suis donc en assez bonne compagnie...
Question bête : comment font ces applications pour écrire leurs fichiers
INI dans Program Files si l'utilisateur n'a pas les droits Admin ?
Pour revenir à mon problème, en fait l'utilisateur de mon appli peut
l'installer où il veut, par défaut il lui est suggéré C:\Program
Files\Toto. Mais il peut aussi l'installer une deuxième fois dans
C:\Toto. Et puis une troisième fois ailleurs, pas forcément dans Program
Files. Dans ce cas, ça devient coton de savoir qui correspond à quoi
dans Documents and Settings\All users\Application Data\etc., sauf à
décider que les paramètres (INI et autres) vont là-dedans si et
seulement si l'appli a été installée dans Program Files, et sinon les
fichiers de paramètres iront dans le répertoire d'installation - à
supposer encore une fois que l'utilisateur à droit d'écriture dedans.
Bref, c'est quand même pas si simple à mon avis.
En fait, le problème majeur, c'est que les différentes installations de
Toto ont forcément des paramètres différents, sinon l'utilisateur
n'installerait qu'une seule fois. Et on pourrait utiliser la base de
registre.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cyrille Szymanski
On 2005-01-29, Bertrand Lenoir-Welter wrote:
Question bête : comment font ces applications pour écrire leurs fichiers INI dans Program Files si l'utilisateur n'a pas les droits Admin ?
Peut-être que ça se passe bien si on utilise des fonctions du genre SetPrivateProfileString() et pas des accès directs aux fichiers ?
Mais il peut aussi l'installer une deuxième fois dans C:Toto. Et puis une troisième fois ailleurs, pas forcément dans Program Files. Dans ce cas, ça devient coton de savoir qui correspond à quoi dans Documents and SettingsAll usersApplication Dataetc., sauf à décider que les paramètres (INI et autres) vont là-dedans si et seulement si l'appli a été installée dans Program Files, et sinon les fichiers de paramètres iront dans le répertoire d'installation - à supposer encore une fois que l'utilisateur à droit d'écriture dedans.
Ce que je ferais c'est que vu que dans le fond c'est la même application mais avec des profils différents, j'utiliserais le même fichier INI avec des sections différentes en fonction du répertoire d'installation et je mettrais ce fichier INI dans le dossier Application Data de l'utilisateur.
En fait, le problème majeur, c'est que les différentes installations de Toto ont forcément des paramètres différents, sinon l'utilisateur n'installerait qu'une seule fois. Et on pourrait utiliser la base de registre.
Tel que je vois la chose une application qui gère bien les profils ferait ça : - les paramètres stockés dans Program Files sont les paramètres par défaut et donc ne sont jamais modifiés ; - ceux dans All Users sont les paramètres globaux de la station de travail et prennent le dessus sur les paramètres par défaut ; - ceux dans le dossier utilisateur sont les paramètres spécifiques à l'utilisateur et prennent le dessus sur les paramètres par défaut et ceux de la station de travail. Il y a deux dossier de ce type : roaming dans User NameApplication Data et non-roaming dans User NameLocal SettingsApplication Data
Pour implémenter ça c'est simple, il suffit de lire les fichiers dans l'ordre, sous réserve de leur existence.
Tout ça pour dire qu'écrire dans Program Files à un autre moment qu'à l'installation, c'est pas une bonne idée.
-- Cyrille Szymanski
On 2005-01-29, Bertrand Lenoir-Welter <bertrand.2004@galaad.net> wrote:
Question bête : comment font ces applications pour écrire leurs fichiers INI
dans Program Files si l'utilisateur n'a pas les droits Admin ?
Peut-être que ça se passe bien si on utilise des fonctions du genre
SetPrivateProfileString() et pas des accès directs aux fichiers ?
Mais il peut aussi l'installer une deuxième fois dans C:Toto. Et puis une
troisième fois ailleurs, pas forcément dans Program Files. Dans ce cas, ça
devient coton de savoir qui correspond à quoi dans Documents and SettingsAll
usersApplication Dataetc., sauf à décider que les paramètres (INI et
autres) vont là-dedans si et seulement si l'appli a été installée dans
Program Files, et sinon les fichiers de paramètres iront dans le répertoire
d'installation - à supposer encore une fois que l'utilisateur à droit
d'écriture dedans.
Ce que je ferais c'est que vu que dans le fond c'est la même application mais
avec des profils différents, j'utiliserais le même fichier INI avec des
sections différentes en fonction du répertoire d'installation et je mettrais ce
fichier INI dans le dossier Application Data de l'utilisateur.
En fait, le problème majeur, c'est que les différentes installations de Toto
ont forcément des paramètres différents, sinon l'utilisateur n'installerait
qu'une seule fois. Et on pourrait utiliser la base de registre.
Tel que je vois la chose une application qui gère bien les profils ferait ça :
- les paramètres stockés dans Program Files sont les paramètres par défaut et
donc ne sont jamais modifiés ;
- ceux dans All Users sont les paramètres globaux de la station de travail
et prennent le dessus sur les paramètres par défaut ;
- ceux dans le dossier utilisateur sont les paramètres spécifiques à
l'utilisateur et prennent le dessus sur les paramètres par défaut et
ceux de la station de travail. Il y a deux dossier de ce type : roaming
dans User NameApplication Data et non-roaming dans
User NameLocal SettingsApplication Data
Pour implémenter ça c'est simple, il suffit de lire les fichiers dans l'ordre,
sous réserve de leur existence.
Tout ça pour dire qu'écrire dans Program Files à un autre moment qu'à
l'installation, c'est pas une bonne idée.
Question bête : comment font ces applications pour écrire leurs fichiers INI dans Program Files si l'utilisateur n'a pas les droits Admin ?
Peut-être que ça se passe bien si on utilise des fonctions du genre SetPrivateProfileString() et pas des accès directs aux fichiers ?
Mais il peut aussi l'installer une deuxième fois dans C:Toto. Et puis une troisième fois ailleurs, pas forcément dans Program Files. Dans ce cas, ça devient coton de savoir qui correspond à quoi dans Documents and SettingsAll usersApplication Dataetc., sauf à décider que les paramètres (INI et autres) vont là-dedans si et seulement si l'appli a été installée dans Program Files, et sinon les fichiers de paramètres iront dans le répertoire d'installation - à supposer encore une fois que l'utilisateur à droit d'écriture dedans.
Ce que je ferais c'est que vu que dans le fond c'est la même application mais avec des profils différents, j'utiliserais le même fichier INI avec des sections différentes en fonction du répertoire d'installation et je mettrais ce fichier INI dans le dossier Application Data de l'utilisateur.
En fait, le problème majeur, c'est que les différentes installations de Toto ont forcément des paramètres différents, sinon l'utilisateur n'installerait qu'une seule fois. Et on pourrait utiliser la base de registre.
Tel que je vois la chose une application qui gère bien les profils ferait ça : - les paramètres stockés dans Program Files sont les paramètres par défaut et donc ne sont jamais modifiés ; - ceux dans All Users sont les paramètres globaux de la station de travail et prennent le dessus sur les paramètres par défaut ; - ceux dans le dossier utilisateur sont les paramètres spécifiques à l'utilisateur et prennent le dessus sur les paramètres par défaut et ceux de la station de travail. Il y a deux dossier de ce type : roaming dans User NameApplication Data et non-roaming dans User NameLocal SettingsApplication Data
Pour implémenter ça c'est simple, il suffit de lire les fichiers dans l'ordre, sous réserve de leur existence.
Tout ça pour dire qu'écrire dans Program Files à un autre moment qu'à l'installation, c'est pas une bonne idée.
-- Cyrille Szymanski
Patrick Philippot
Bertrand Lenoir-Welter wrote:
Il me semble que je suis donc en assez bonne compagnie...
Question bête : comment font ces applications pour écrire leurs fichiers INI dans Program Files si l'utilisateur n'a pas les droits Admin ?
Bonjour,
En NTFS, elles ne peuvent pas. Si l'utilisateur n'a pas les droits, l'application ne peut pas transgresser ces permissions. Si elle le pouvait, cela voudrait dire que la sécurité de Windows ne fonctionne pas. Et malgré les légendes urbaines, ce n'est pas vrai :-) .
Beaucoup d'applications n'ont pas été mises à jour pour tenir compte de ces nouvelles contraintes de XP. Si vous utilisez ces applications sans les droits adéquats sur le répertoire de l'application, il y aura une erreur, visible ou non. Dans certains cas, l'application constatera l'erreur mais ne signalera rien. Les options du .INI ne seront simplement pas mises à jour.
Ceci étant, il n'est pas nécessaire de donner à l'utilisateur les droits de l'Admin. Il s'agit de l'autoriser à écrire dans *un* répertoire particulier sur *un* fichier particulier (le .INI de l'application) et pas un autre quand on constate que le problème se pose pour une application donnée. Je parle de NTFS, évidemment.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bertrand Lenoir-Welter wrote:
Il me semble que je suis donc en assez bonne compagnie...
Question bête : comment font ces applications pour écrire leurs
fichiers INI dans Program Files si l'utilisateur n'a pas les droits
Admin ?
Bonjour,
En NTFS, elles ne peuvent pas. Si l'utilisateur n'a pas les droits,
l'application ne peut pas transgresser ces permissions. Si elle le
pouvait, cela voudrait dire que la sécurité de Windows ne fonctionne
pas. Et malgré les légendes urbaines, ce n'est pas vrai :-) .
Beaucoup d'applications n'ont pas été mises à jour pour tenir compte de
ces nouvelles contraintes de XP. Si vous utilisez ces applications sans
les droits adéquats sur le répertoire de l'application, il y aura une
erreur, visible ou non. Dans certains cas, l'application constatera
l'erreur mais ne signalera rien. Les options du .INI ne seront
simplement pas mises à jour.
Ceci étant, il n'est pas nécessaire de donner à l'utilisateur les droits
de l'Admin. Il s'agit de l'autoriser à écrire dans *un* répertoire
particulier sur *un* fichier particulier (le .INI de l'application) et
pas un autre quand on constate que le problème se pose pour une
application donnée. Je parle de NTFS, évidemment.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Il me semble que je suis donc en assez bonne compagnie...
Question bête : comment font ces applications pour écrire leurs fichiers INI dans Program Files si l'utilisateur n'a pas les droits Admin ?
Bonjour,
En NTFS, elles ne peuvent pas. Si l'utilisateur n'a pas les droits, l'application ne peut pas transgresser ces permissions. Si elle le pouvait, cela voudrait dire que la sécurité de Windows ne fonctionne pas. Et malgré les légendes urbaines, ce n'est pas vrai :-) .
Beaucoup d'applications n'ont pas été mises à jour pour tenir compte de ces nouvelles contraintes de XP. Si vous utilisez ces applications sans les droits adéquats sur le répertoire de l'application, il y aura une erreur, visible ou non. Dans certains cas, l'application constatera l'erreur mais ne signalera rien. Les options du .INI ne seront simplement pas mises à jour.
Ceci étant, il n'est pas nécessaire de donner à l'utilisateur les droits de l'Admin. Il s'agit de l'autoriser à écrire dans *un* répertoire particulier sur *un* fichier particulier (le .INI de l'application) et pas un autre quand on constate que le problème se pose pour une application donnée. Je parle de NTFS, évidemment.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
