Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Probleme avec fopen et CreateFile sous windows

Probleme avec fopen et CreateFile sous windows

22 réponses
Avatar
Thomas Boidron
Bonjour,

j'ai un programme qui est dans C:\program files\MonProg\

qui crée un fichier option.txt (avec fopen ouCreatefile) lorquil est lancé.

Mon probleme est le suivant:


si je crée un racourci vers mon executable alors le fichier option.txt est
crée dans

le repertoire ou se trouve le raccourci au lieu d'etre crée dans le
repertoire ou se trouve l'executable.

Quelqu'un peut-il m'aider?

Merci d'avance.
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2 3
Avatar
Arnaud Debaene
Pierre Maurette wrote:
En fait, il me semble clair que Thomas veut que option.txt continue à
être créé dans le répertoire de l'exécutable. Son problème vient du
fait qu'à un moment il a édité un raccourci à la main (par exemple),
et que le répertoire courant n'est plus celui de l'exécutable. Il me
semble que le répertoire courant d'un process lancé par un raccourci
est dans le champs "Démarrer dans" s'il est renseigné, et par défaut
celui du raccourci.
Si le programme est lancé via un raccourci, ce qui n'est qu'une des X

options possibles.

Ce qui est moins clair, c'est la position de Thomas par rapport à
MonProg. Est-ce un programme de son cru? Souhaite-t-il le modifier? Je
veux dire que le fait que le répertoire courant et le répertoire de
l'exécutable soient différents peut avoir d'autres conséquences.
Certainement, donc il faut le gérer.


Le
mieux est peut-être de faire en sorte que les deux chemins soient les
mêmes, comme c'était le cas, ce qui est facile en regardant ce qu'est
un raccourci. C'est même comme ça qu'il est fait par défaut par clic
droit/créer un raccourci.
Sauf qu'il n'y a aucun moyen de contrôler comment l'utilisateur va lancer

ton programme....

Corrigez-moi si je me trompe: le répertoire courant défini par le
lancement d'un programme est stable, en ce sens que c'est une variable
propre au process que lui seul peut ultérieurement modifier.
Oui, par contre il n'y a aucun moyen de garantir sa valeur au lancement du

programme.

Arnaud

Avatar
James Kanze
"Arnaud Debaene" writes:

|> wrote:
|> > "Arnaud Debaene" wrote in message
|> > news:<40baf1f6$0$23506$...

|> > De l'autre : quel rapport entre le répertoire courant et le chemin
|> > de l'executable ? Que je sois sous Unix ou sous Windows,
|> > l'executable n'est pour ainsi dire jamais dans le répertoire
|> > courant.

|> L'OP n'était pas trop clair de de savoir s'il voulait créer son
|> fichier option.txt dans le répertoire courant ou bien dans le
|> répertoire de l'executable.

En effet. Si je rémonte jusqu'à son premier posting, c'est clair. Mais
pourquoi alors a-t-il parlé du répertoire courant.

|> Dans les 2 cas, c'est une solution spécifique à l'OS :
|> GetCurrentDirectory pour le répertoire courant ou
|> GetModuleFileName(NULL) pour le répertoire de l'executable.

Tout à fait. Enfin, en supposant qu'une telle requête existe -- sous
Unix, au moins, il n'y a rien qui ressemble au séconde ci-dessu (en
supposant qu'elle fait ce que je crois qu'elle fait).

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Avatar
James Kanze
Pierre Maurette writes:

|> "Arnaud Debaene" typa:

|> > wrote:

|> >> "Arnaud Debaene" wrote in message
|> >> news:<40baf1f6$0$23506$...

|> >> De l'autre : quel rapport entre le répertoire courant et le
|> >> chemin de l'executable ? Que je sois sous Unix ou sous Windows,
|> >> l'executable n'est pour ainsi dire jamais dans le répertoire
|> >> courant.

|> >L'OP n'était pas trop clair de de savoir s'il voulait créer son
|> >fichier option.txt dans le répertoire courant ou bien dans le
|> >répertoire de l'executable.

Enfin quelque chose sur laquelle on est d'accord:-).

|> >Dans les 2 cas, c'est une solution spécifique à l'OS :
|> >GetCurrentDirectory pour le répertoire courant ou
|> >GetModuleFileName(NULL) pour le répertoire de l'executable.

|> En fait, il me semble clair que Thomas veut que option.txt continue
|> à être créé dans le répertoire de l'exécutable.

En a-t-il le droit ? Sur les systèmes que je connais (y compris Windows
NT), ce n'est pas normalement le cas.

|> Son problème vient du fait qu'à un moment il a édité un raccourci à
|> la main (par exemple), et que le répertoire courant n'est plus celui
|> de l'exécutable. Il me semble que le répertoire courant d'un process
|> lancé par un raccourci est dans le champs "Démarrer dans" s'il est
|> renseigné, et par défaut celui du raccourci.

Qu'est-ce qui t'a fait pensé ça ? Il n'a rien dit sur tout ça. A priori,
pourquoi penser à un racourci, plutôt qu'un effet du $PATH (qui marche
exactement sous Windows comme sous Unix).

|> Ce qui est moins clair, c'est la position de Thomas par rapport à
|> MonProg. Est-ce un programme de son cru? Souhaite-t-il le modifier?

C'est ce qu'il a dit.

|> Je veux dire que le fait que le répertoire courant et le répertoire
|> de l'exécutable soient différents peut avoir d'autres conséquences.

Je dirais qu'il sont rarement identique. La plupart des programmes que
tu exécutes sont bien des programmes du système, dans les répertoires où
tu n'as même pas le droit d'écrire. Tandis que chaque utilisateur qui se
loggue à un répertoire courrant différent par défaut.

|> Le mieux est peut-être de faire en sorte que les deux chemins soient
|> les mêmes, comme c'était le cas, ce qui est facile en regardant ce
|> qu'est un raccourci. C'est même comme ça qu'il est fait par défaut
|> par clic droit/créer un raccourci.

|> Corrigez-moi si je me trompe: le répertoire courant défini par le
|> lancement d'un programme est stable, en ce sens que c'est une
|> variable propre au process que lui seul peut ultérieurement
|> modifier.

C'est le cas sous Unix. Ce n'était pas le cas sous MS-DOS -- je ne sais
pas où il en est avec Windows.

|> Le programme "Agent", celui que j'utilise actuellement, utilise le
|> champs "Démarrer dans" pour n'autoriser qu'une instance par compte,
|> mais autant d'instances qu'il y a de comptes.

Là, je ne te suis pas. Qu'est-ce qui m'empêche de créer plusieurs
raccourcis avec des champs « Démarrer dans » différents ? Ou simplement
de le lancer depuis la ligne de commande à partir des répertoires
différents ?

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Avatar
Arnaud Debaene
James Kanze wrote:
Dans les 2 cas, c'est une solution spécifique à l'OS :
GetCurrentDirectory pour le répertoire courant ou
GetModuleFileName(NULL) pour le répertoire de l'executable.



Tout à fait. Enfin, en supposant qu'une telle requête existe -- sous
Unix, au moins, il n'y a rien qui ressemble au séconde ci-dessu (en
supposant qu'elle fait ce que je crois qu'elle fait).
Ca récupère le nom complet de l'executable du programme (càd le module

principal du processus, les autres modules étant les DLLs chargées).
En effet, ca n'existe pas sous Unix et c'est vraiment dommage.

Arnaud



Avatar
Pierre Maurette
"Arnaud Debaene" typa:

Pierre Maurette wrote:

Le
mieux est peut-être de faire en sorte que les deux chemins soient les
mêmes, comme c'était le cas, ce qui est facile en regardant ce qu'est
un raccourci. C'est même comme ça qu'il est fait par défaut par clic
droit/créer un raccourci.
Sauf qu'il n'y a aucun moyen de contrôler comment l'utilisateur va lancer

ton programme....
J'en conviens. Bricoler le raccourci n'est qu'une façon rapide de

répondre à la question posée.
Considérer "répertoire courant == répertoire de l'exécutable" va
fonctionner en lançant l'exe par double clic ou par un raccourci créé
par l'explorer.
Il serait utile au minimum de forcer le répertoire de travail à celui
de l'exécutable dès les inits.
<HS>
C'est immédiat en utilisant la VCL :
char lpBuffer[512];
int result = GetModuleFileName(NULL, lpBuffer, 512);
if((result != 0) && (result != 512)){
SetCurrentDirectory(ExtractFilePath(AnsiString(lpBuffer)).c_str());}
</HS>
A partir de là on travaille en chemins relatifs.
Pour des trucs plus compliqués le mieux est d'initialiser d'une façon
ou d'une autre une série de string correspondant aux différents
chemins ou fichiers utilisés. Indispensable si l'utilisateur peut
paramétrer ces chemins (sauvés dans un .ini, la base de registre je
n'en ai jamais eu l'utilité).

Corrigez-moi si je me trompe: le répertoire courant défini par le
lancement d'un programme est stable, en ce sens que c'est une variable
propre au process que lui seul peut ultérieurement modifier.
Oui, par contre il n'y a aucun moyen de garantir sa valeur au lancement du

programme.
J'ai voulu vérifier ce que la doc disait des fichiers .lnk

(raccourcis). Comme prévu, ils génèrent une ligne de commande. En
fait, pour le champ "Démarrer dans", la seule source que j'ai trouvé
parle de "working directory", il me semble évident qu'il s'agit du
répertoire courant.
En revanche, je n'ai pu trouver l'info que si un raccourci dont ce
champ est laissé vide est lancé par double-clic, alors le répertoire
courant initial du process est celui du raccourci. Simplement, je
constate ce comportement sur ma bécane. De toutes façons, c'est peu
important, il n'est pas bon de compter sur un comportement par défaut,
et de plus le répertoire du raccourci est rarement (n'ai pas dit
jamais!) intéressant.
--
Pierre


Avatar
Pierre Maurette
James Kanze typa:

Pierre Maurette writes:

|> En fait, il me semble clair que Thomas veut que option.txt continue
|> à être créé dans le répertoire de l'exécutable.

En a-t-il le droit ? Sur les systèmes que je connais (y compris Windows
NT), ce n'est pas normalement le cas.
N'avez-vous pas sous NT des X:Program FilesMonProgMonProg.ini

conjointement avec X:Program FilesMonProgMonProg.exe (ce n'est
qu'un exemple) ?

|> Son problème vient du fait qu'à un moment il a édité un raccourci à
|> la main (par exemple), et que le répertoire courant n'est plus celui
|> de l'exécutable. Il me semble que le répertoire courant d'un process
|> lancé par un raccourci est dans le champs "Démarrer dans" s'il est
|> renseigné, et par défaut celui du raccourci.

Qu'est-ce qui t'a fait pensé ça ? Il n'a rien dit sur tout ça. A priori,
pourquoi penser à un racourci, plutôt qu'un effet du $PATH (qui marche
exactement sous Windows comme sous Unix).

|> Ce qui est moins clair, c'est la position de Thomas par rapport à
|> MonProg. Est-ce un programme de son cru? Souhaite-t-il le modifier?

C'est ce qu'il a dit.
Explication de texte :


<Bonjour,> Thomas nous salue.

<j'ai un programme qui est dans C:program filesMonProg
qui crée un fichier option.txt (avec fopen ouCreatefile) lorquil est
lancé.> Thomas a un programme qui crée un fichier lorsqu'il est lancé.
L'a-t-il écrit ? Thomas seul le sait, mais c'est fort possible.

<Mon probleme est le suivant:> Thomas a un problème dont il va nous
entretenir.

<si je crée un racourci vers mon executable alors le fichier
option.txt est crée dans le repertoire ou se trouve le raccourci au
lieu d'etre crée dans le repertoire ou se trouve l'executable.> Là,
c'est un peu moins trivial. J'interprête le "au lieu de" en partant du
principe que Thomas a un problème "si [il] crée un raccourci". Ce qui
donne : tout va bien, le programme (lancé d'une façon non précisée)
crée option.txt dans le répertoire de l'exécutable. Thomas crée alors
(comment?) un raccourci, le programme écrit alors option.txt dans le
répertoire du raccourci. Et c'est celà qui gêne Thomas.

<Quelqu'un peut-il m'aider?> Intelligent, Thomas pose la plus ouverte
des questions.

<Merci d'avance.> Thomas nous remercie. A nouveau, Thomas est fort
civil.

Thomas pose-t-il une question de programmation ? Ou simplement s'en
pose-t-il sur les raccourcis et la notion de répertoire courant ?
Faut-il le rediriger vers un groupe traitant d programmation Windows,
ou alors d'utilisation de Windows ? Son message suivant <Donc comment
faire pour connaitre le repertoire courant?> ne nous éclaire pas
beaucoup.


|> Le programme "Agent", celui que j'utilise actuellement, utilise le
|> champs "Démarrer dans" pour n'autoriser qu'une instance par compte,
|> mais autant d'instances qu'il y a de comptes.

Là, je ne te suis pas. Qu'est-ce qui m'empêche de créer plusieurs
raccourcis avec des champs « Démarrer dans » différents ? Ou simplement
de le lancer depuis la ligne de commande à partir des répertoires
différents ?
C'est bien ce qui se passe. Un raccourci par compte. Simplement pour

dire que le lancement par raccourcis offre des possibilités
intéressantes. Ce qui ne dispense pas de gérer les lancements
"sauvages".
--
Pierre

Avatar
adebaene
Pierre Maurette wrote in message news:...
James Kanze typa:

Pierre Maurette writes:

|> En fait, il me semble clair que Thomas veut que option.txt continue
|> à être créé dans le répertoire de l'exécutable.

En a-t-il le droit ? Sur les systèmes que je connais (y compris Windows
NT), ce n'est pas normalement le cas.
N'avez-vous pas sous NT des X:Program FilesMonProgMonProg.ini

conjointement avec X:Program FilesMonProgMonProg.exe (ce n'est
qu'un exemple) ?
Oui, et avec une installation par défaut l'utilisateur lambda n'as pas

le droit en écriture sur ce fichier.

Arnaud


Avatar
Alexandre
N'avez-vous pas sous NT des X:Program FilesMonProgMonProg.ini
conjointement avec X:Program FilesMonProgMonProg.exe (ce n'est
qu'un exemple) ?


si, hélas souvent beaucoup de programmes placent leurs données dans leur
propre dossier... Et souvent, l'utilisateur n'a PAS le droit d'écriture
dedans. Ce qui ne se voit souvent pas lors d'un test trivial (sur la machine
de dev, où le developpeur est souvent admin) mais quand on déploie. Un
exemple : Borland C++ Builder 3 écrit des paramètres dans un fichier .$$$
situé dans son dossier BIN, hors mes étudiants n'ont pas le droit d'écriture
dedans, donc il ne se lance pas ....
Pas cool.

Avatar
kanze
Pierre Maurette wrote in message
news:...
James Kanze typa:

Pierre Maurette writes:

|> En fait, il me semble clair que Thomas veut que option.txt
|> continue à être créé dans le répertoire de l'exécutable.

En a-t-il le droit ? Sur les systèmes que je connais (y compris
Windows NT), ce n'est pas normalement le cas.


N'avez-vous pas sous NT des X:Program FilesMonProgMonProg.ini
conjointement avec X:Program FilesMonProgMonProg.exe (ce n'est
qu'un exemple) ?


Parfois, mais pas en général.

Un répertoire comme c:Program Files fait partie du système. Et un
utilisateur normal n'y a pas droit d'y écrire à volenté. Il faut, par
exemple, un fichier .ini par utilisateur ; sinon, si je change ma
configuration, ta configuration change aussi. Alors, ou bien, il y a un
sous-répertoire par utilisateur dans c:Program FilesMonProg, et c'est
dans ce sous-répertoire où on travaille, ou bien, il y a un espèce de
HOME pour chaque utilisateur, avec un sous-répertoire pour MonProg. Sous
Unix, c'est prèsque toujours cette dernière solution qui prévaut, à
certaines exceptions près (comme Star Office). Sous Windows, c'est
mélangé, mais j'ai l'impression que la première solution est plus
courante.

Évidemment, il pourrait exister une troisième solution, ou MonProg
utilisait <utilisateur>.ini, à la place de MonProg.ini, mais je ne
connais pas de programmes qui fonctionne comme ça.

[...]
C'est bien ce qui se passe. Un raccourci par compte. Simplement pour
dire que le lancement par raccourcis offre des possibilités
intéressantes. Ce qui ne dispense pas de gérer les lancements
"sauvages".


On est donc d'accord. J'avoue que j'ai une tendance à considérer le cas
tordu dès le départ. Ça fait plus de trente ans que je programme, et je
constate que s'il y a un cas auquel on n'a pas pensé, c'est précisement
ce cas-là qui va intéresser l'utilisateur.

Je connais mal Windows, alors, suite à tes réponses, j'y ai fait un
essai. Il m'a fallu moins de 10 minutes pour invoquer un programme qui
n'avait pas le chemin (ni même le nom du programme) en argv[0]. Ce n'est
donc pas une solution robuste.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Avatar
heinquoi
a écrit dans le message de
news:
Je connais mal Windows, alors, suite à tes réponses, j'y ai fait un
essai. Il m'a fallu moins de 10 minutes pour invoquer un programme qui
n'avait pas le chemin (ni même le nom du programme) en argv[0]. Ce n'est
donc pas une solution robuste.


je suis intéressé par la façon dont tu à mis argv[0] en non valide arg,
pourrais tu nous en dire plus ?

--
Cordialement,
Heinquoi

1 2 3