4. Mingw32 / CodeBlocks : fopen falscher return Wert bei kompilieren auf 64bit System

Mingw32 / CodeBlocks : fopen falscher return Wert bei kompilieren auf 64bit System

  • E

    Hallo,

    ich hatte dieses Problem schonmal an anderer Stelle beschrieben, aber dort hat es nicht so ganz reingepasst.

    Folgendes Problem:

    Wenn das Beispiel-Programm unten unter gewissen vorraussetzungen kompiliere, meldet fopen keinen Fehler.
    Sollte es aber eigentlich (permission denied).

    funktioniert:

    kompilieren auf 64bit Windows (7 oder 8.1) mit
    - mingw64 (als 64bit binary)
    - VSC++ 2010 Express (als 32bit binary)

    komilieren auf 32Bit Windows (8.1)
    - mit mingw32

    funktioniert nicht:

    kompilieren auf 64Bit windows (7 oder 8.1) mit
    - mingw32
    - VSC++ 2010 (in Codeblocks statt VS)

    Ich weiss nicht wo ich da ansetzen soll. Kenne mich auch nicht soo gut damit aus.
    In meinem anderen Beitrag wurde vermutet es könnte etwas mit der gelinkten msvcrt version zu tun haben.

    mingw linkt wohl gegen msvcrt und visual studio gegen msvcr100.
    Aber mit der msvcrt geht es ja auch. halt nur nicht unter den beschriebenen Bedingungen.

    Über Hilfe würde ich mich freuen. Problem ist halt kompilieren eines 32Bit binarys, das den Fehler korrekt meldet,
    funktioniert auf meinem 64Bit (Hauptsystem) nur im VS 2010 Express. Ich würde aber lieber Codeblocks verwenden.
    Und die normale msvcrt, da diese auf allen Windows Systemen vorhanden ist.

    #include <stdio.h>

int main(void)
{
	FILE *fp;

	fp = fopen("C:\\Program Files\\testfile.txt", "w+");

	if(fp == NULL)
	{
		perror("fopen error");
		return 1;
	}

	if(fclose(fp) == EOF)
	{
		perror("fclose error");
		return 1;
	}

	return 0;
}
    0
  • S

    Mach doch mal einen Check mit ferror wenn du einen Stream-Pointer zurück bekommst.

    0
  • E

    ferror liefert 0

    auch nach einem fputc in den scheinbar geöffneten Dateistream.
    und fclose.

    die Datei wird aber nicht angelegt, weil ja keine Berechtigung vorhanden ist.
    wäre ja auch noch schöner...

    0
  • S

    Das klingt dann aber schon so als würde da eine Datei zum Schreiben geöffnet sein.
    Einfach mal 1M Daten reinschreiben um zu sehen was passiert wenn die Buffer des Streams gefüllt werden.
    Irgendwann muss er das ja auf die Platte schreiben. Und ein Tool für Offene-Dateien Anzeigen unter Windows wäre ganz hilfreich. Damit man sehen kann ob da eventuell irgendwo anders eine Datei geöffnet wurde.

    Ansonsten wäre das ganz schön abgedreht und irgendwie glaube ich nicht das die Funktionen so falsch liegen.

    0
  • ?

    Über welche Version(en) der msvcrt geht es überhaupt?
    Für 32-Bit-Programme auf 64-Bit_Systemen liegt die in *c:\Windows\SysWOW64*

    Bist du dir sicher, dass auch die msvcrt genommen wird und nicht die msvcpp?
    (Compilierst du bei jedem deiner Versuche im C-Modus?)

    Hast du es schon mal mit statischem Linken probiert?

    0
  • ?

    Bei mir steht die Datei dann in

    c:\Users\%USERNAME%\AppData\Local\VirtualStore\Program Files\

    bzw.

    %userprofile%\AppData\Local\VirtualStore\Program Files\

    Aber das hatte ich ja schon (nicht so exakt) im anderen Thread geschrieben: https://www.c-plusplus.net/forum/p2435644#2435644

    0
  • E

    @DirkB
    Ja Du hass recht, da wird die Datei erstellt.
    Kann man das irgendwie unterbinden?

    Wäre schon schön wenn ich "permission denied" bekäme statt dass er die Datei dann dort anlegt...

    EDIT:
    Und bleibt noch die Frage warum das nur unter den beschriebenen Umständen so ist.

    0
  • E

    Ok, man kann das in der Systemsteuerung deaktivieren ...

    Lokale Sicherheitsrichtlinie -> Lokale Richtlinien -> Sicherheitsoptionen -> Benutzerkontensteuerung: Datei- und Registrierungsschreibfehler an Einzelbenutzerstandorte virtualisieren

    dann kommt auch wie erwartet ein "permission denied" beim Versuch in C:\Program Files\ die Datei zu erstellen.

    Hmm.. schon etwas blöd wenn ich jetzt dort eine Datei erstelle und keine Fehlermeldung erhalte.
    Wenn dann ein anderes Programm die Datei dort nicht finden kann,
    das erstellende Programm aber meldete es hätte die Datei erfolgreich erstellt.

    .. wer sich das ausgedacht hat ....

    Fehler gefunden, beheben geht wohl nicht wirklich.
    Naja, zumindest kann ich jetzt mal davon ausgehen das meine kompilierten Programme in Ordnung sind. 🙂

    EDIT:
    Also es ist wohl so das man in der Manifestdatei "kompatibel zu Vista oder höher" angeben muss damit nichts umgeleitet wird.
    Das würde auch erklären warum es mit dem in VisualStudio kompilierten Programm funktioniert.
    Ich gehe mal davon aus, dass das in den Projektvorlagen so eingestellt ist.
    Werds mal ausprobieren...

    0
  • E

    Ich habe jetzt mal ausprobiert.

    Mit einem Manifest, das kompatibilität zu Vista angibt tritt das Problem nicht mehr auf.

    0
Anmelden zum Antworten