Forums

Hello, non dans la pratique, mais plus dans l'exercice théorique, j'aimerais avoir une petite information sur wine, et non PlayOnLinux (mais comme les deux sont intimements liés, j'imagine que bon nombres de personnes connaissant très bien wine sont dans le coin.)

Bon, ma question est simple, par défaut, wine ne permet pas à des fichiers appartenant à un utilisateur X, d'être exécutés par un utilisateur Y ou Z.

Comment faire en sorte que wine se contente des accès en écriture et lecture sans faire attention au propriétaire?


Si l'on essaie de le lancer sans être le propriétaire des fichiers, on obtient une phrase de type "wine [chemin de l’exécutable] is not owned by you"


Il y a bien une astuce qui consiste à créer un utilisateur wine, à rajouter dans son groupe les autres utilisateurs, etc... Mais ça n'est ni pratique, ni propre et ça tient plus de la bidouille qu'autre chose.

À noter que s'il faut compiler wine avec certains arguments, ça ne me posera pas de problème. :)

J'imagine qu'on peut empêcher ça, mais il faudra à mon avis modifier le code source de wine

Je pense que si ils ont mit cette option, c'est pour éviter des bugs.

Sauf qu'en l’occurrence, ça m'arrange pas du tout :-/

Après je peux comprendre que dans certains cas, ça puisse poser des problèmes de droits, mais je cherche à reproduire le comportement de wine intégré dans picassa de google, donc c'est uniquement pour une application spécifique à chaque fois.

Ils ont fait un paquet intégrant à la fois leur programme, leur préfixe, et wine, avers des fichiers appartenant à root, et le programme pouvant être exécuté par tous les utilisateurs d'un système.

Je veux reproduire la même chose

Pourquoi ça ne t'arrange pas ? Un patch et puis ça roule

T'es sur que picassa ils ne copient pas le préfixe dans un dossier temporaire au lancement ? Regarde leur script de lancement si ce n'est pas déjà fait

Déjà fait, et ça ne semble pas être le cas, ils ont bien un dossier caché créé dans le home de l'utilisateur, mais il ne sert qu'à conserver les préférences du programme pour l'utilisateur comme il en serait le cas sous windows. (sans compter que leur paquet est blindé de scripts en tout genre, difficilement compréhensibles)

Après pour le patch, le problème, c'est que je ne suis pas développeur donc mettre mon nez dans le code source de wine, autant dire que c'est mal barré... Et je n'ai pas connaissance de l'existence d'un tel patch non plus.

Edité par billou

Pour commencer, il faudrait chercher dans quel fichier est le message alertant que l'utilisateur n'est pas propriétaire du préfixe

J'ai trouvé 3 fichiers ayants "is not owned by you" !


~/wine-src/libs/wine/config.c

~/wine-src/dlls/ntdll/server.c

~/wine-src/server/request.c

Edité par billou

En replaçant les fatal_error des printf, je suppose que ça devrait fonctionner

Bon, bha comme on dit, y'a plus qu'à; je vais essayer ça, je compile, et je te dis de quoi il en retourne , merci ! :)

Edité par billou

Bon, je viens de tenter, ça fonctionne en partie.

Je m'explique, les exécutables se lancent depuis un autre compte utilisateur désormais, je ne suis plus bloqué après le message concernant les droits, par contre, les paramètres ne sont pas conservé par le programme, à chaque lancement du jeu, il refait la recherche des paramètre et réagit comme si je le lançais pour la première fois.

J'ai eu exactement le même comportement quand j'ai tenté de renommer le dossier /drive_c/users/monlogin sous un autre nom et en essayant de remplacer toutes les annotations "monlogin" par un autre nom dans les fichiers system.reg, user.reg et userdef.reg

Il doit y avoir un truc tout bête qui bloque.

T'as une idée?


Edit : J'ai trouvé un début de réponse, c'est sans doute pas parfait encore, mais tout se lancer correctement, il faut créer un dossier ayant le nom de l'utilisateur qui va lancer l’exécutable, dans /drive_c/users/nom-de-l'user et un autre à l'intérieur de celui ci ayant le nom "Mes Documents" (les fichiers de préférence du jeu concerné et les sauvegardes sont enregistrés dans Mes Documents)

Voilà comment je pense faire les choses désormais :

1 - Un script lance le programme
2 - Le script va avant toute chose, vérifier avec la variable $USER si le dossier de l'utilisateur est existant dans /drive_c/users
3 - S'il n'existe pas, on crée un dossier tel que $HOME/.programme , puis un lien symbolique de ce dossier sur /driver_c/users/nom-de-l'user/Mes Documents
S'il existe, on saute, et on passe directement au lancement de l'application. :)

Il reste cependant un problème, le dossier Mes Documents a été pris tel quel en Français par wine, mais que se passera t'il si le système de l'utilisateur est dans une autre langue?... Wine aura il besoin d'un "Mes Documents" tel que "My Documents"?

Edité par billou

Pour l'anglais je pense que en effet, il faut respecter la langue.

Tu peux toujours essayer de forcer l'anglais pour tout le monde, et d'appeler le dossier "My Documents"

Justement, comment forcer wine à prendre l'anglais comme langue par défaut?

Essais avec export LANG="en.US-utf8"

Hum, visiblement, ça ne convient pas, ça réinitialise tout.

Wine n'a pas un fichier de configuration ou quelque chose du genre?

Non. Comment ça ça réinitialise tout ?

L'application concernée nécessite d'être réinstallée dès que je change les "locales", m'enfin de toute façon il est seulement en Français, pour là, ça ira, par contre il faudra que je pense à ça pour les programmes multilingues.

Bon, ça a l'air de fonctionner en tout cas, je concocterais un paquet 7zip prêt à l'emploi pour l'exemple, et il faudrait que je fasse un tutoriel clair, pour ceux qui voudraient reproduire le concept.

Edité par billou

ENFIN, j'ai transposé à l'écrit un tutoriel !

http://doc.ubuntu-fr.org/integrer-applications-windows-dans-paquets-logiciels

Edité par billou