|
| [WD17] : écriture dans dossier ProgramData sous Windows 10 |
| Débuté par ag.norton-consulting, 18 mar. 2016 17:47 - 4 réponses |
| |
| | | |
|
| |
Membre enregistré
5 messages |
|
| Posté le 18 mars 2016 - 17:47 |
Bonjour,
Je fais des déplacements de fichiers de paramétrage sous le dossier c:\ProgramData (fct fdéplacefichier), ainsi que des écritures dans cette arborescence (iniecrit et écriture dans fichier .fic).
Cela fonctionne parfaitement sous Windows 7, par contre sur mes machines en Windows 10 non.
J'ai un accès refusé, malgré que j'ai mis au minimum le controlé de compte UAC
Quelqu'un a-t-il une idée ?
Merci d'avance pour toute réponse. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
214 messages |
|
| Posté le 07 juin 2016 - 12:24 |
Bonjour,
Avez-vous trouvé une solution, car je rencontre un problème +- similaire avec une de mes applications:
L'exécutable est sous programfiles.
Les données (.fic) sont sous programdata.
Le programme ne nécessite pas les droits d'administrateur (il respecte l'UAC de Windows).
Le programme fonctionne correctement sous windows 7,8 et 10.
La ou je rencontre un soucis, c'est lors de la mise à jour de windows 7 vers 10 (mise à jour automatique non choisie par les clients m'ayant remonté le problème actuellement):
Le répertoire programdata\monappli passe en lecture seule lors du lancement du programme. La seule façon que j'ai trouvé pour contourner le problème est d'éxécuter le programme en tant qu'administrateur.
Cordialement, |
| |
| |
| | | |
|
| | |
| |
| Posté le 03 octobre 2016 - 11:19 |
Bonjour,
Je remonte ce post car je rencontre également des problème similaires.
Mon appli est sous WD20, et distribuée sur des clients qui n'ont pas le même profils : certains sont admin de leurs postes, d'autres non, sous divers systèmes d'exploitations...
Les fichiers de données sont sous ProgramData/nomSociété/...
L'exécutable est défini avec le manifest droits maxi de l'utilisateur.
Dans le cas d'un utilisateur standard, si l'appli est installée en tant qu'admin depuis la session de l'utilisateur, tout se passe bien ensuite lors de l'execution du programme en tant qu'utilisateur standard.
Si par contre on installe l'appli "en tant que un autre utilisateur administrateur " (l'informaticien du client fait l'installation), alors l'utilisateur standard ne peut pas écrire dans le fichier de données.
Tout se passe comme si "programData" était protégé par Windows. Du coup je peux contourner le problème en plaçant les fichiers de données dans un autre dossier auquel on met tous les droits, ou sous "appData" s'il n'y a qu'un utilisateur, mais je trouve ça aberrant que "programData" ne puisse pas servir pour les données commune.
Ce comportement est applicable sous Windows 10 par défaut, mais pas toujours et pas uniquement. J'ai eu le problème sur des pc sous un domaine et sous Seven.
Est-ce que quelqu'un sait comment contourner le problème, ou dois-je changer "programData" par une autre dossier par défaut ? |
| |
| |
| | | |
|
| | |
| |
| Posté le 17 octobre 2018 - 10:58 |
Je remonte ce post, pour savoir si quelqu'un a une solution ?
Chez certains clients avec W10, l'écriture dans ProgramData fonctionne parfaitement, chez d'autres, l'écriture ne fonctionne pas, "accès refusé", c'est assez pénalisant. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
182 messages |
|
| Posté le 18 octobre 2018 - 15:21 |
Hello,
S'il y a de l'écriture dans ce dossier, l'UAC est désactivé dans ce cas.
Sur la LST 114, il y a justement un exemple sur cela :
WD Gestion UAC
L'exemple WD Gestion UAC propose une collection de procédures permettant d'interagir avec l'UAC (User Account Control ou Contrôle de Compte Utilisateur) depuis une application WINDEV. Ces procédures peuvent être utilisées pour lancer des applications ou des commandes en forçant l'élévation de privilèges ou au contraire en restreignant les privilèges de l'utilisateur.
Si tu veux être tranquille, plutôt qu'utiliser ce dossier, tu peux utiliser le dossier local de l'utilisateur en cours avec "SysRep(srAppDataLocal)" |
| |
| |
| | | |
|
| | | | |
| | |
|