Impossible d'écrire/créer un fichier

**Xelland** · 01/08/2020, 20h35

Bonjour

J'ai un programme qui n'a pas le même comportement sur 2 ordis différents (pourtant même OS : Win 7 64bits; j'ai même tenté sur Win 8 et je ne reproduis pas)
Mon problème est que je n'ai pas accès à l'ordi qui a l'erreur (donc échanges par mail/téléphone)
donc pour diagnostiquer

J'ai la fonction CreateFile qui génère l'erreur : aucune création du fichier
GetLastError me retourne l'erreur ERROR_ACCESS_DENIED
L'exécutable est lancé sur le disque C

J'appelle CreateFile avec ces paramètres :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    HANDLE hFile;
    hFile = CreateFile ("log.txt",
                        GENERIC_WRITE,
                        0,
                        NULL,
                        OPEN_ALWAYS,
                        FILE_ATTRIBUTE_NORMAL,
                        NULL);

alors que la lecture du fichier (s'il existe) fonctionne
La création/modification du fichier est possible avec le bloc notes

Comment savoir ce qui empêche l'écriture ?
Comment corriger ?

Merci

**Bousk** · 02/08/2020, 05h15

L'erreur est probablement en dehors du programme. Autre chose a déjà ouvert le fichier et le maintien.
Sur Windows 10, nous avons remarqué que VS a du mal à écraser l'exe après compilation quand... le dossier qui le contient est ouvert et que les fichiers sont réordonnés par date et non par l'ordre par défaut.

**Sve@r** · 02/08/2020, 10h28

Bonjour

Pour faire suite au post de Bousk (qui te répond à 5h15 un dimanche quand il rentre de boite

), il faut voir si la suppression est possible (une bête suppression par clic droit). S'il est vraiment maintenu par un autre truc, la suppression sera impossible. Toutefois si la modification par bloc note est possible cela pourrait alors signifier que l'hypothèse du maintien n'est pas la bonne.

Il faudrait aussi peut-être essayer de corriger le chemin (ie hFile = CreateFile ("c:\...\...\log.txt", ...) car avec un chemin relatif "log.txt" le fichier sera créé à l'endroit où tu te trouves quand tu appelles le programme. Ainsi déjà tu seras sûr que tu le crées au bon endroit et que c'est bien ce fichier dont il s'agit.

**foetus** · 02/08/2020, 11h46

Envoyé par Sve@r

Bousk (qui te répond à 5h15 un dimanche quand il rentre de boite

Il me semble qu'il poste ces derniers temps à cette heure : donc non

Envoyé par Sve@r

Il faudrait aussi peut-être essayer de corriger le chemin (ie hFile = CreateFile ("c:\...\...\log.txt", ...) car avec un chemin relatif "log.txt" le fichier sera créé à l'endroit où tu te trouves quand tu appelles le programme. Ainsi déjà tu seras sûr que tu le crées au bon endroit et que c'est bien ce fichier dont il s'agit.

Je vais faire mon vieux chiant

, mais depuis Windows 10, (mais initié avec Vista et surtout Windows 8), tu as 1 grosse architecture de dossiers, et évidemment chacun à ses droits.
Par exemple, le dossier ProgramData, tu peux lire, mais pour modifier il faut les droits du logiciel. Pour le dossier AppData, la lecture et l'écriture est libre (ce sont tes droits)

Donc, si @Xelland veut utiliser 1 dossier sur le disque système, le mieux est de passer par l'API Windows : SHGetKnownFolderPath et les Ids des dossiers

Code approximatif :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
    PWSTR path = NULL;
 
    HRESULT hr = SHGetKnownFolderPath(&FOLDERID_Documents, 0, NULL, &path);
 
    if ( SUCCEEDED(hr) ) {
        size_t folder_path_size = wcslen(path);
 
        if (path[folder_path_size - 1] != L'\\') { folder_path_size++; }
 
        if ((folder_path_size + 7) < MAX_PATH) {
            wchar_t file_path[MAX_PATH];
            HANDLE hFile;
 
            if (path[folder_path_size - 1] != L'\\') {
                wcsprintf(file_path, L"%s\\%s", path, L"log.txt");
            } else {
                wcsprintf(file_path, L"%s%s", path, L"log.txt");
            }
 
            hFile = CreateFile(file_path, GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
 
//         ....
        } /* else manage error */
    } /* else manage error */
 
    CoTaskMemFree(path);

**Sve@r** · 02/08/2020, 13h18

Envoyé par foetus

Il me semble qu'il poste ces derniers temps à cette heure : donc non

Ben, si, c'est le temps des vacances donc il est en boite tout le temps

Envoyé par foetus

Donc, si @Xelland veut utiliser 1 dossier sur le disque système, le mieux est de passer par l'API Windows

Oui éventuellement dans un second temps. Mais d'abord essayer la première version sur un autre chemin permettrait de détecter si le souci vient du programme ou du chemin.

**Bousk** · 02/08/2020, 20h38

Vu que tu es sur Win7, et que ça se lance dans C, il faut vérifier les permissions de l'utilisateur, de son groupe AD, de la machine, etc.
Ouvrir juste log.txt va l'ouvrir à côté de l'exe, ce qui n'est pas terrible. Depuis une certaine version de Win7 il me semble que les fichiers devraient être ouverts dans un dossier où l'écriture est permise, généralement le dossier User ou AppData. Et que Microsoft a renforcé les restrictions dans les dossiers systèmes et Program Files où c'était yolo auparavant.

Reste ce dont je parlais dans mon premier post : une restriction cachée de Windows que nous avons constaté. Depuis la dernière màj de Windows, ou peut-être la précédente, nous étions nombreux à avoir des erreurs d'écriture de fichier après une compilation - l'exe final.
Nous pouvons ouvrir les fichiers dans le dossier, et les modifier. Nous pouvons aussi supprimer l'exe problématique, et bien sûr sa création fonctionne alors.
Mais quand VS finit de compiler et veut écraser l'exe, erreur d'accès.
Et nous avons remarqué que quand l'explorer est ouvert dans le dossier où l'exe sort, et que les fichiers sont réordonnés par date (parce que nous voulons avoir les logs récents en haut), l'erreur se produit. L'erreur a été remonté à MS il me semble.
Donc il existe des morceaux de magie noire pas ou peu documentés.
Donc est-ce que l'erreur se produit alors qu'un fichier existe déjà uniquement ? Ou bien sa création initiale échoue aussi ?
Tu pourrais aussi utiliser un nom plus unique, qui contient une date d'exécution par exemple, afin d'avoir non pas un unique gros log.txt mais de plus petits pour chaque lancement. Et si la création initiale fonctionne tout le temps, ça corrigera le problème au passage.

ps: svear : ta théorie est intéressante, mais la réalité est plus simple : https://fr.wikipedia.org/wiki/Fuseau_horaire et tu remarqueras le drapeau Canadien dans mon profil

. Ce que tu appelles 5h15 un dimanche matin, j'appelle samedi 23h15

.

**Xelland** · 03/08/2020, 09h20

Envoyé par Sve@r

il faut voir si la suppression est possible (une bête suppression par clic droit). S'il est vraiment maintenu par un autre truc, la suppression sera impossible. Toutefois si la modification par bloc note est possible cela pourrait alors signifier que l'hypothèse du maintien n'est pas la bonne.

Il faudrait aussi peut-être essayer de corriger le chemin (ie hFile = CreateFile ("c:\...\...\log.txt", ...) car avec un chemin relatif "log.txt" le fichier sera créé à l'endroit où tu te trouves quand tu appelles le programme. Ainsi déjà tu seras sûr que tu le crées au bon endroit et que c'est bien ce fichier dont il s'agit.

je vais voir avec un chemin absolu
sinon je pense à l'antivirus ou un problème de droits, mais la personne n'étant pas informaticienne, je vais m'amuser pour expliquer

mais je ne vois pas pourquoi l'antivirus bloquerait la création d'un fichier qui n'est pas dans un dossier système

Envoyé par Bousk

Donc est-ce que l'erreur se produit alors qu'un fichier existe déjà uniquement ? Ou bien sa création initiale échoue aussi ?

l'erreur se produit :
- création initiale => pas de création
- fichier existe déjà => le fichier n'est pas écrasé

Envoyé par Bousk

Tu pourrais aussi utiliser un nom plus unique, qui contient une date d'exécution par exemple, afin d'avoir non pas un unique gros log.txt mais de plus petits pour chaque lancement. Et si la création initiale fonctionne tout le temps, ça corrigera le problème au passage.

le code original est bien plus gros
j'ai isolé la partie qui pose problème et la personne reproduit avec ce simple appel à CreateFile
donc à priori pas un problème dans le nom du fichier

**foetus** · 03/08/2020, 09h26

Envoyé par Xelland

l'erreur se produit :
- création initiale => pas de création
- fichier existe déjà => le fichier n'est pas écrasé

Ouais

cela sent les droits d'écriture que tu n'as pas pour le dossier

**Xelland** · 04/08/2020, 11h43

Envoyé par foetus

Ouais

cela sent les droits d'écriture que tu n'as pas pour le dossier

la personne avait mis exécutable dans un dossier en dessous de "Mes Documents"

En mettant l'exe sous C:\TEMP, là tout fonctionne correctement

Envoyé par Sve@r

Mais d'abord essayer la première version sur un autre chemin permettrait de détecter si le souci vient du programme ou du chemin.

C'était bien le chemin

Bizarre, sur mon poste, je n'ai pas ce problème sous "Mes Documents", peut-être une différence dans les droits ou une mise à jour sur un des 2 postes

**foetus** · 04/08/2020, 12h18

Envoyé par Xelland

je n'ai pas ce problème sous "Mes Documents"

Moi je ne trouve cela pas anormal, même normal

1 programme n'est pas censé écrire ses données dans ce dossier. Il y a par exemple, les dossiers ProgramData (pour tous les utilisateurs) et AppData (pour 1 utilisateur particulier)
Avec 1 ordinateur public ou pro, le dossier "Mes Documents" peut-être + ou - bloqué, parce que c'est le dossier par défaut de téléchargement des butineurs Internet, et donc 1 porte ouverte pour tout 1 tas de cochonneries. Cela peut être aussi faire parti d'1 politique que l'utilisateur ne peut rien installer, et donc on s'assure qu'il ne puisse pas télécharger de logiciels.

**Sve@r** · 04/08/2020, 15h42

Envoyé par Xelland

C'était bien le chemin

Nom : 18020301335723496215532527.gif
Affichages : 691
Taille : 9,7 Ko

Impossible d'écrire/créer un fichier

C

Discussions similaires

Partager

Partager