Impossible d'écrire/créer un fichier

Version imprimable

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 :roll:

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:

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

02/08/2020, 05h15
Bousk

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.
02/08/2020, 10h28
Sve@r

Bonjour

Pour faire suite au post de Bousk (qui te répond à 5h15 un dimanche quand il rentre de boite :mouarf:), 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.

Citation:

Envoyé par Sve@r

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

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

Citation:

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 :wow:, 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 : :whistle:
Code:

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);

02/08/2020, 13h18
Sve@r

Citation:

Envoyé par foetus

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

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

Citation:

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.
02/08/2020, 20h38
Bousk

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 :toutcasse:.
03/08/2020, 09h20
Xelland

Citation:

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 :mrgreen:
mais je ne vois pas pourquoi l'antivirus bloquerait la création d'un fichier qui n'est pas dans un dossier système

Citation:

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é

Citation:

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
03/08/2020, 09h26
foetus

Citation:

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 :whistle: cela sent les droits d'écriture que tu n'as pas pour le dossier
04/08/2020, 11h43
Xelland

Citation:

Envoyé par foetus

Ouais :whistle: 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 :D

Citation:

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
04/08/2020, 12h18
foetus
Citation:

Envoyé par Xelland

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

Moi je ne trouve cela pas anormal, même normal :mrgreen:
- 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.
04/08/2020, 15h42
Sve@r

1 pièce(s) jointe(s)

Citation:

Envoyé par Xelland

C'était bien le chemin

Pièce jointe 576600