Logiciel avec dossier profile dans "application data"

[biobio67]

Salut,
Je suis en train de tester de "portabiliser" un logiciel, qui est déjà très portable en soi, sauf un répertoire qui se crée dans les "application data". Dans le tuto je n'ai pas trouvé de piste comment faire pour que le logiciel va enregistrer ce répertoire sur la clé...
est-ce qu'il y a des pistes quelque part pour faire cela?

Merci pour la réponse...

[1138]

Hello !

J'ai le même genre de souci. Je souhaite portabiliser Wormux mais il écrit des données de configuration dans "Application Data\Wormux"

Sur le forum de PortableApps, quelqu'un a proposé une version portable détournant ce problème mais qui ne me satisfait pas : il renomme temporairement un éventuel fichier "config.xml" dans "Application Data\Wormux" pour y placer celui de son Wormux portable (et opération inverse à la fermeture du programme).

Mais je n'aime pas trop cette idée : en cas de plantage, la configuration de la machine hôte devient celle du programme portable. De plus, Wormux met d'autres choses dans "Application Data\Wormux" (dernier terrain utilisé, équipes personnalisées, etc.)

N'y a-t-il pas moyen que le lanceur fasse croire à Wormux qu'il écrit dans "Application Data\Wormux" mais que, en réalité, ce le soit dans un dossier "settings" ou autre ?

[cyrille]

Vous pouvez voir les deux fils de discussion liés à la portabilisation d'autres logiciels :
http://forum.framasoft.org/viewtopic.php?f=73&t=30526
http://forum.framasoft.org/viewtopic.php?f=73&t=30554

Cela devrait vous permettre de réussir.

Bon courage

[pyg]

Effectivement, il est possible comme l'a indiqué Cyrille de changer les variables d'environnement avec un bête :

Code: Tout sélectionner

; Fake home directory
  ProfileEnvironment:
; Set the %HOMEDRIVE%%HOMEPATH% directory if we have a path
    StrCmp $ProfileDir "" ExecApp
    IfFileExists "$ProfileDir\*.*" "" ExecApp
   Push "$EXEDIR"
   Call GetRoot
   Pop "$Drive"
   
   StrCpy "$ProfileDir" "$ProfileDir" "" 2
   
   System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("HOMEDRIVE", "$Drive").r0'
   
   System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("HOMEPATH", "$ProfileDir").r0'


http://nsis.sourceforge.net/Setting_Env ... s_Examples

Mais j'avoue que j'ai toujours des réticences à utiliser ce genre de feintes : on pourrait en effet imaginer que le programme ainsi détourné lance un autre logiciels (ou d'autres processus) qui seraient alors redirigés vers le dossier sur la clé.
Du coup, ce logiciels pourrait servir à récupérer des données "non autorisées".

Bref, à utiliser avec précautions.
http://portableapps.com/node/13903

[Téthis]

Mais j'avoue que j'ai toujours des réticences à utiliser ce genre de feintes : on pourrait en effet imaginer que le programme ainsi détourné lance un autre logiciels (ou d'autres processus) qui seraient alors redirigés vers le dossier sur la clé.
Du coup, ce logiciels pourrait servir à récupérer des données "non autorisées".

Je ne vois pas en quoi le fait de changer des variables d'environnement te donne cette impression. On peut imaginer n'importe quoi à partir de rien du tout. Le fait de corriger à l'avance les répertoires utilisés par le programme n'est en rien un truc malsain, c'est fait pour ça les variables d'environnements.

Le fait que, pour l'utilisateur lambda, ce ne soit pas trivial quand on utilise les API ne doit pas te donner l'impression d'un truc louche.

[pyg]

Oh, je n'y vois rien de louche. C'est juste que je ne trouve pas ça propre : avec cette méthode, tous les sous-processus lancés par le logiciels en question utiliseront la même variable d'environnement. C'est cela qui ne me plait pas.

Si je lance PortableXXXX, qui va lancer le processus Y, alors ce processus X Y utilisera le "faux" dossier Application Data de la clé (arrête moi si je me trompe, c'est ce que j'ai compris à la lecture de la doc, mais je ne prétends pas être un expert).

Dans une grande majorité des cas, pas de probleme. Mais imaginons que j'utilise ma framakey sur une machine dont je ne soit pas l'utilisateur principal et que le processus Y soit un service installé "en dur" sur la machine (je sais pas moi: un antivirus, googleupdate,... bref, un soft utilisé normalement par l'utilisateur initial de la machine). Alors ce processus pourrait
1) mal s'executer (ne retrouvant pas ses petits à l'endroit habituel
2) stocker des infos de l'utilisateur initial sur la clé (pour un service de log par exemple)
3) (à vérifier, je n'en ai pas la moindre idée) devenir instable si l'on retire la clé et que le processus Y continue de tourner.

Précisons :
- je ne suis pas un expert, si je dis des conneries faut me le dire (et m'indiquer des références/sources, histoire que je ne meurs pas idiot)
- je ne suis pas paranoïaque, et ce genre de modif ne m'inquiète pas outre mesure (et je vois donc tous les softs que tu as portabilisé d'un tres bon oeil, ils seront d'ailleurs sur le portail Framakey avant la fin de semaine)
- cependant, si (notez le conditionnel) les 3 points que j'ai cité plus haut sont potentiellement vrais, alors on ne peut raisonnablement pas indiquer la réécriture de variables comme "la" solution. Sinon, tout le monde utiliserait cette technique sans penser aux éventuelles conséquences.

[Téthis]

Oh, je n'y vois rien de louche. C'est juste que je ne trouve pas ça propre : avec cette méthode, tous les sous-processus lancés par le logiciels en question utiliseront la même variable d'environnement. C'est cela qui ne me plait pas.

Si je lance PortableXXXX, qui va lancer le processus Y, alors ce processus X Y utilisera le "faux" dossier Application Data de la clé (arrête moi si je me trompe, c'est ce que j'ai compris à la lecture de la doc, mais je ne prétends pas être un expert).

Oui, en principe ils héritent de l'environnement du processus père, donc du dossier Applications Data redéfini (je préfère cet adjectif à faux ).

Au premier abord, je ne pense pas que cela pose problème qu'une application installée sur la machine utilise ce répertoire redéfini. Les données qu'elle utilisera seront vierges ou spécifique à la clef car le répertoire de correspond à celui d'un autre HOME, il ne devrait donc pas y avoir de terribles conflits avec les données du HOME originel. Cela demanderait à être tester in silicon.

Et d'un autre côté, si on lance une application à partir d'une autre application de la framakey sans redéfinir les variables d'environnement, on interfère avec les données locales car on les utilise, voire les redéfinit, alors qu'on est sensé utiliser la clef pour ne pas toucher la machine. Dilemme.

[edit dedenimes]correction de balise[/edit]