C fopen échoue pour écrire avec errno est de 2

Je ne comprends pas pourquoi c'est apparemment échoue avec errno 2:

char debugText [256];
sprintf (debugText, "C:\\List.txt");
dfile = fopen( debugText, "w");
fprintf ( dfile, "  err %d \n", errno);

Je dis apparemment parce que tout dfile est NULL, le fichier est créé et est rempli avec de ma sortie.

donc ce qui se passe ?

Ce type est dfile? Où est le test pour NULL?
jetez un oeil à strerror() qui retourne une chaîne de caractères qui explique errno pour vous.
(Pour les googlers)Pour moi, c'était que le dossier avait pas les autorisations d'écriture. Sur Windows: clic Droit > Propriétés > > Modifier. Ensuite, permettre de le modifier pour tous les utilisateurs

OriginalL'auteur JPM | 2013-04-01

  1. 8

    Tout ce que vous avez dit est que errno a la valeur 2 après votre fopen appel. Vous ne savez pas que l'appel a échoué, parce que vous n'avez pas vérifier si les dfile == NULL. Si la sortie a été écrit dans le fichier, sans doute le fopen appel a réussi et le errno valeur a été laissé plus d'un certain appel, probablement l'une que vous n'avez pas explicitement.

    À défaut, les appels peuvent définir errno à une valeur non-nulle valeur, mais le succès des appels ne pas ensemble errno à 0. Pour vérifier les erreurs, vous devez

    • Ensemble errno à 0 avant l'appel;
    • Faire l'appel et vérifier la valeur retournée pour voir si elle a réussi ou échoué; et
    • Vérifier la valeur de errno après l'appel -- mais seulement si vous savez qu'il a échoué (sinon, la valeur de errno est vide de sens).

    Si defile == NULL, puis le fprintf appel a un comportement indéfini; il ne sera probablement pas.

    D'autre part, vous dites que dfile est NULL. Comment le savez-vous? Votre code n'est pas le vérifier. (Si le fopen appel a vraiment fait échouer, pourrait le contenu de C:\List.txt être de gauche au cours d'une exécution précédente de votre programme?)

    Ce que la sortie ne vous obtenez à partir de ce programme?

    #include <stdio.h>
#include <errno.h>
int main(void) {
    char debugText [256];
    FILE *dfile;

    sprintf (debugText, "C:\\List.txt");
    dfile = fopen( debugText, "w");
    if (dfile == NULL) {
        printf("fopen failed, errno = %d\n", errno);
    }
    else {
        printf("fopen succeeded\n");
    }
    return 0;
}
    Je vois dfile est NULLE parce que je suis l'exécution pas à pas en mode debug. c'est quand j'ai commencé à l'accaparement des errno.
    Vous devez vérifier si defile == NULL dans votre programme, et puis ne pas essayer d'écrire dans le fichier si il est. Pour vérifier pourquoi fopen() ne marche pas, comme je l'ai suggéré avec errno. En supposant que vous êtes sur un système Windows, ouverture "C:\\List.txt" pour la sortie ne devrait pas échouer avec errno==2, qui signifie "No such file or directory". (Vous sur Windows, non? Et pas sous Cygwin?)
    Essayez le programme que je viens d'ajouter à ma réponse.

    OriginalL'auteur Keith Thompson

  2. 4
    2 ENOENT No such file or directory.  A component of a specified pathname
         did not exist, or the pathname was an empty string.

    Voici une liste des codes d'erreur:

    http://www.thegeekstuff.com/2010/10/linux-error-codes/

    Mais vous devriez vérifier si fopen() retourné NULL d'abord parce que cette valeur dans errno peut-être laissé quelque chose d'autre.

    OriginalL'auteur Johnny Mnemonic

  3. 3

    Pas de fonction de bibliothèque de jamais jeux de errno à zéro.

    Vous ne devriez vérifier errno après une fonction signale une erreur.

    Par exemple, votre code doit être:

    if ((dfile = fopen(debugText, "w")) == 0)
    ...then fopen() failed and errno is relevant...

    Si la fonction n'est pas une défaillance de l'état, la valeur de errno peut-être rien. Par exemple, sur un système Solaris, vous finissent souvent avec errno ensemble de ENOTTY après une opération réussie, parce que stdout n'est pas connecté à un terminal. Cela ne signifie pas que quelque chose s'est mal passé; cela signifie simplement qu'un test pour savoir si la sortie standard est un terminal d'échec (car il n'est pas un terminal).

    si le fichier n'existe pas fopen est censé supprimer et puis créer un nouveau. clairement le chemin n'est pas vide, ni le chemin inexistant: C:\ donc, ce que je n'obtiens est pourquoi dfile est NULL. sauf QUE c'est un aberratioin de VS2010 ?
    Vous n'avez pas à prouver que dfile == NULL; en effet, depuis les suivantes fprintf() l'utilise, il est improbable que dfile est null (vous auriez probablement obtenir un crash dans fprintf() si elle était nulle). Vous devriez réviser votre code explicitement test dfile avant je serais disposé à croire que votre affirmation que dfile est nul (et de rendre compte de l'erreur sur un canal autre que dfile).

    OriginalL'auteur Jonathan Leffler