fopen - keine Datei Schreibrechte, aber keine Fehlermeldung



  • Hallo Forum und ein frohes neues Jahr erstmal!

    Ich habe mich seit längerer Zeit mal wieder etwas mit programmieren beschäftigt und habe jetzt folgendes Problem.

    System ist Windows 8.1 mit minGW

    Ich will mit fopen eine Datei erzeugen.
    Das ganze funktioniert auch, nur nicht wenn ich das Programm in einem Verzeichnis ausführe in dem der User (kein Administrator Konto) keine Schreibrechte hat, also z.B. in C:\Programme. Dann läuft das Programm durch, aber die Datei wird nicht erzeugt. Die perror Anweisung wird nicht ausgeführt.

    Es funktioniert dann nur wenn das Programm mit "als Administrator ausführen" gestartet wird.

    [code"=c"]
    #include <stdio.h>
    #include <errno.h>

    int main(void)
    {
    FILE *fp;

    fp = fopen("testfile.txt", "w+");

    if(fp == NULL)
    {
    perror("Error");
    }

    else
    {
    fputs("blabla", fp);
    fclose(fp);
    }

    return 0;
    }
    [/code]

    fopen mit w+ sollte doch eigentlich NULL zurückliefern bei nicht ausreichenden Rechten. So habe ich es jedenfalls in mehreren Quellen gelesen.

    Wo liegt der Fehler?

    Ist schon ne weile her das ich programmiert habe, und damals noch unter Linux...



  • Such mal nach der Datei in deinem Userordner und den Unterverzeichnissen.

    Du kannst im Windowsexplorer in der Adresszeile %homepath% eingeben.



  • Das hier ist nur eine Vermutung, ich habe kein Windows und kann es deswegen nicht testen:

    Wenn du als normaler User keine Berechtigung zur Dateierstellung hast, kannst du keine Dateien anlegen. (Hier die Vermutung). Die Windows C-lib scheint aber dennoch bei man: fopen kein NULL sondern ein FILE -Objekt zu liefern, deswegen wird man: perror(3) nicht ausgeführt. In diesem Fall wird man: fputs ausgeführt aber das Schreiben scheitert.

    Probiere mal

    #include <stdio.h>
    #include <errno.h>
    
    int main(void)
    {
        FILE *fp;
    
        fp = fopen("testfile.txt", "w+");
    
        if(fp == NULL)
        {
            perror("Error");
        }
    
        else
        {
            int ret = fputs("blabla", fp);
            printf("fopen returned a FILE object and fputs %d", ret);
            perror("Has there been an error at all?");
        }
    
        fclose(fp);
    
        return 0;
    }
    

    führt mal diesen Code aus, vielleicht kannst du da sehen, was tatsächlich passiert. Wenn ich bei meiner Vermutung richtig liege, wirst du sowas bekommen:

    fopen returned a FILE object and fputs -1
    Has there been an error at all?: <some error message>
    


  • @DirkB
    Hm.. also die Datei wird ja schon in dem Verzeichnis erstellt wo sich die .exe befindet, falls schreibrechte vorhanden.

    Also:

    ich habe das ganze jetzt mal mit Visual Studio Express 2010 compiliert und das Programm macht was es soll.

    hier die Consolen ausgabe

    C:\Program Files>testpr.exe
    Error: Permission denied
    

    Es liegt also irgendwie am compiler.



  • Seit Windows 7 werden einige Systemordner im Userverzeichnis gespiegelt.
    Mein Verdacht war halt, dass die Datei dort angelegt wurde.

    Das Verhalten hängt dann aber auch vom Verzeichnis ab.



  • Man sollte auch nicht vergessen, besonders nach dem Schreiben einer Datei, den Returncode von fclose auszuwerten.



  • @DirkB
    Achso, das wusste ich nicht 😉

    @fclose
    ja, keine schlechte idee

    Zum Problem: Es scheint wirklich an minGW zu liegen, ich habe es jetzt nochmal mit minGW-w64 compiliert und es funktioniert.

    Allerdings habe ich dann ein 64Bit binary. Naja muss ich nochmal etwas rumtüfteln damit ich 32Bit compiliert bekomme...



  • minGW linkt gegen msvcrt ( Microsoft Visual C Run-Time Library).
    http://en.wikipedia.org/wiki/Microsoft_Windows_library_files#MSVCRT.DLL_and_MSVCPP.DLL

    Daher sollte es egal sein, welchen Compiler du nimmst.
    Evtl. brauchst du eine andere msvcrt.



  • Hm, also ich habe jetzt nochmal mehrere Versionen von MinGW-w64 (mingw-builds von SourceForge) probiert.

    alle 32bit Versionen produzieren das fehlerhafte Programm.
    Nur mit den 64Bit Versionen erhalte ich ein Programm dass korrekt die Fehlermeldung ausgibt.

    Ich habe auch mal mingw-w64 auf einem 32Bit Windows 8.1 in einer VirtualBox probiert. Da ich dachte es liegt evtl. daran das ich auf einem 64Bit System kompiliere, aber selbes Problem.

    Welche msvcrt brauche ich denn? Ich steige da nicht so ganz durch.
    Wird die genutzt die im System installiert ist oder die, die der jeweilige Kompiler mitbringt?

    Wird die dann statisch ins fertige Programm eingebunden, oder später jeweils dynamisch geladen?

    Das Programm sollte ja mal auf jedem Windows laufen später...

    Wie gesagt ist es schon recht lange her das ich mich mit der Materie befasst habe. Deshalb bitte nachsichtig sein 😉

    Das muss doch irgendwie gehen. Ich würde erstmal nur ungern Visual Studio benutzen.



  • Die Compiler produzieren keinen fehlerhaften Code.
    Du produzierst den in deinen Augen fehlerhaften Programmaufruf selbst, also liegt es nur an deiner Umgebung. Das dort rauszufinden hat nichts mit C zu tun.



  • Ok, ok ..

    Nach etwas beschäftigung mit der Materie bin ich wieder etwas besser in der ganzen Thematik Compiler, Linker usw.

    Den Fehler zu finden habe ich zwar nicht geschafft, aber etwas schlauer bin ich schon geworden.

    VS-C++ 2010 linkt gegen eine msvcr100d, mit der funktioniert es.
    Welche msvcrX mingw32 linkt weiss ich nicht, aber es wird wohl die msvcrt sein,
    mit der es nicht funktioniert.

    Da es die msvcr100d wohl nicht auf allen Windows Systemen von Haus aus gibt kommt die für mich nicht in Frage.

    Ob es aber wirklich nur an der msvcrt liegt, da bin ich mir nicht wirklich sicher.
    Ich habe das kleine Programm mal nur mit Win32 API Funktionen geschrieben und das zeigt das gleiche verhalten. Ob da jetzt trotzdem die msvcrt genutzt wird weiss ich nicht. Habe mich gerade mal ein paar Tage damit befasst. 😉

    Das reine C Programm ist also Ok, aber in gewisser Weise hat das ganze ja schon was mit C zu tun...


Anmelden zum Antworten