IsFileInUse : Ergebnis unterschiedlich im Admin-Modus

[Harry Stahl]

Tja, man kann sich wohl nicht mehr unbedingt so auf altbekannte Funktionen verlassen.

Viele nutzen sicher in einer ähnlichen Variante eine Funktion "IsFileInUse", wie z.B. hier dargestellt:

http://solvedstack.com/questions/che...open-in-delphi

Gerade stelle ich fest, dass diese Funktion für alle Dateien, die im Programmverzeichnis liegen, das Ergebnis "True" (also offen, bzw. in Benutzung) zurückliefert, auch wenn die gar nicht in Benutzung sind (vermute, dass das wohl ab Windows Vista schon so ist?).

Lediglich wenn man sein Programm im Admin-Modus ausführt, wird das korrekte Ergebnis zurückgeliefert.

Für mein Dateimanager-Programm verwende ich zwar schon ein Extra-Modul mit Adminmodus für alle Aktionen, die im Programm- oder Systemverzeichnis stattfinden sollen (also kopieren, löschen, umbenennen), aber die Suchfunktion ist noch im Hauptmodul (das standardmäßig im User-Modus läuft), möchte ungern an dieser Stelle für die Suchfunktion (Suchen in Dateien) wieder alles umstricken.

Kennt jemand eine Variante, wie man das korrekte Ergebnis erhält, ohne den Admin-Modus zu verwenden?

[Bernhard Geyer]

Die Funktion hat schon immer ihre Probleme wenn sie wegen Rechtprobleme eine Datei nicht zum schreiben öffnen darf

[Der schöne Günther]

Was hast du denn erwartet? Die Funktion tut nichts anderes als zu versuchen die Datei zum Schreiben zu öffnen. Dann sagt sie, ob es fehlgeschlagen ist. Ohne Administratorrechte kannst du natürlich auch keine Systemdateien verändern.

Das "in use" ist eigentlich schon irreführend. Jemand kann genauso gut in eine Datei schreiben und den Zugriff trotzdem nicht verbieten. Dann ist die Datei eigentlich "in use", wird auch aktiv verändert, und deine Funktion schlägt trotzdem nicht fehl und sagt "Nö, ist nicht in use".

[p80286]

Die Funktion sollte besser "kannIchSchreiben" heißen. InUse stimmt spätestens seit Dos 3.1 nicht mehr.

Gruß
K-H

[Dalai]

Zitat von p80286:

Die Funktion sollte besser "kannIchSchreiben" heißen.

... wenn sie den invertierten Boolean-Wert zurückgibt (ohne Adminrechte gibt sie True zurück).

MfG Dalai

[Harry Stahl]

Zitat von Der schöne Günther:

Was hast du denn erwartet? Die Funktion tut nichts anderes als zu versuchen die Datei zum Schreiben zu öffnen. Dann sagt sie, ob es fehlgeschlagen ist. Ohne Administratorrechte kannst du natürlich auch keine Systemdateien verändern.

Ja, das ist ein berechtigter Hinweis. Man sollte sich die verwendeten Parameter doch ein wenig genauer ansehen.

Letztlich will ich ja auch nur wissen, ob ich die Datei öffnen kann, schreiben will ich ja gar nicht, sondern nur durchsuchen.

Insofern mache ich da jetzt einfach was passendes draus (lasse also generic_write weg) und schon läuft es wie gewünscht:

Delphi-Quellcode:

function CanOpenFile(fName: string; CheckIfExist: Boolean) : boolean;
var
  HFileRes: HFILE;
begin
  Result := False;

  if (CheckIfExist=True) and (not FileExists(fName)) then begin
    Exit;
  end;

  HFileRes := CreateFile(PChar(fName)
    ,GENERIC_READ
    ,0
    ,nil
    ,OPEN_EXISTING
    ,FILE_ATTRIBUTE_NORMAL
    ,0);

  Result := (HFileRes <> INVALID_HANDLE_VALUE);

  if Result then begin
    CloseHandle(HFileRes);
  end;
end;

[Sir Rufo]

Nichts ist älter als der Status von eben

Eben war die datei noch zu öffnen und jetzt, wo du sie öffnen möchtest, ist die gerade gesperrt worden.

Das einfachste ist, die Datei direkt zu öffnen und auf entsprechende Fehler/Exceptions zu reagieren (z.B. x mal versuchen und dann erst mit der Exception abbrechen).

Was du jetzt machst ist die Datei zu öffnen und wieder zu schliessen um diese dann wieder zu öffnen ...

Und eine Datei, die nicht existiert, bekommst du mit den Parametern nicht geöffnet, somit ist der Parameter CheckIfExists irgendwie unnütz.

If ( CheckIfExists = true ) and ...
Warum nicht viel lesbarer if CheckIfExists and ... ?

[Harry Stahl]

Zitat von Sir Rufo:

Nichts ist älter als der Status von eben

Eben war die datei noch zu öffnen und jetzt, wo du sie öffnen möchtest, ist die gerade gesperrt worden.

Das einfachste ist, die Datei direkt zu öffnen und auf entsprechende Fehler/Exceptions zu reagieren (z.B. x mal versuchen und dann erst mit der Exception abbrechen).

Was du jetzt machst ist die Datei zu öffnen und wieder zu schliessen um diese dann wieder zu öffnen ...

Und eine Datei, die nicht existiert, bekommst du mit den Parametern nicht geöffnet, somit ist der Parameter CheckIfExists irgendwie unnütz.

Dass die Datei existiert, weiß ich schon wenn ich die CanOpenFile-Funktion aufrufe, will es daher in dieser Funktion nicht noch einmal prüfen (wenn man die Funktion 100.000 mal aufruft, kann das schon zeitlich was ausmachen).

Die Prüfung (ob man die Datei öffnen kann) hatte ich wohl (ist schon ein paar Jahre her) vermutlich eingeführt, weil es anscheinend zu größeren Problemen kommen konnte, wenn man versucht eine gesperrte Datei zu öffnen / oder weil es sich dann zeitlich spürbar verschlechterte.

Grundsätzlich versuche ich es immer so zu machen, dass die Frage, ob etwas geht oder nicht, möglichst nicht mit dem Auslösen einer Exception geklärt wird.

Muss ich mir im vorliegenden Fall aber noch mal überlegen. Ist ja eher unwahrscheinlich, dass die zu durchsuchenden Dateien gesperrt sind, insofern könnte das "doppelte" öffnen tatsächlich mehr Zeit kosten, als der (evtl.)" Wurf von einigen Exceptions.

Zitat von Sir Rufo:

If ( CheckIfExists = true ) and ...
Warum nicht viel lesbarer if CheckIfExists and ... ?

Jupp, das war ein Rest von was anderem, ist schon weg

[uligerhardt]

Zitat von Harry Stahl:

http://solvedstack.com/questions/che...open-in-delphi

FWIW: Das scheint mir so eine überflüssige Abkupferseite zu sein. Ich denke, das ist das Original: http://stackoverflow.com/questions/1...open-in-delphi