FindFirstFileNameW aufrufen

[Benmik]

Für ein geplantes selbst gestricktes Backup-Programm möchte ich gern bei Hardlinks feststellen, welche Dateinamen alle auf den gleichen Speicherbereich ("Datei") zeigen. Nach viel Recherche bin ich darauf gekommen, dass hier FindFirstFileNameW und FindNextFileNameW genau das Richtige sind.
Die Windows-API definiert FindFirstFileNameW(_In_ LPCWSTR lpFileName,_In_ DWORD dwFlags,_Inout_ LPDWORD StringLength,_Inout_ PWCHAR LinkName) und FindNextFileNameW(_In_ HANDLE hFindStream,_Inout_ LPDWORD StringLength,_Inout_ PWCHAR LinkName).
Trotz des Anspruchs, dass Delphi die gesamte Windows-API kapselt, habe ich nichts dergleichen gefunden.
Erstaunlicherweise ergibt die Google-Suchen nach den Funktionen im Zusammenhang mit Delphi NIX, GAR NIX !
Ich müsste also die Funktionen dynamisch aus kernel32 laden.
Hierzu habe ich für GetTickCount64 ein Beispiel gefunden:

Delphi-Quellcode:

function GetTickCount64: Int64;

implementation

uses Windows, SysUtils;

type
   // Don't forget stdcall for API functions.
  TGetTickCount64 = function: Int64; stdcall;

var
  _GetTickCount64: TGetTickCount64;

// Load the Vista function if available, and call it.
// Raise EOSError if the function isn't available.
function GetTickCount64: Int64;
var
  kernel32: HModule;
begin
  if not Assigned(_GetTickCount64) then begin
    // Kernel32 is always loaded already, so use GetModuleHandle
    // instead of LoadLibrary
    kernel32 := GetModuleHandle('kernel32');
    if kernel32 = 0 then
      RaiseLastOSError;
    @_GetTickCount := GetProcAddress(kernel32, 'GetTickCount64');
    if not Assigned(_GetTickCount64) then
      RaiseLastOSError;
  end;
  Result := _GetTickCount64;
end;

Weiß einer von den Delphi-Cracks hier vielleicht, wie die beiden Funktionen aufzurufen wären?

[Sir Rufo]

AFAIK wird mit SysUtils.FindFirst SysUtils.FindNext genau das gekapselt.
Das Ergebnis findest du im SysUtils.TSearchRec

[himitsu]

FindFirst kapselt FindNextFile (FindNextFileA und ab D2009 FindNextFileW),
aber hier geht es um FindNextFileNameW.

Das geht genauso, wie im Beisiel:
- Funktions-Typ deklarieren (entsprechend wie TGetTickCount64 die API-Deklaration übersetzen)
- über LoadLibrary die DLL laden, oder via GetModuleHandle das Handle holen, wenn die DLL definitiv schon geladen ist
- den Prozedur-Einsprungpunkt holen (GetProcAddress) und der Variable des Funktionstyps zuweisen
(und dafür gibt es eigentlich millionen Beispiele und Tutorials zu finden, wie man eine API/WinAPI einbindet, auch wenn es kaum welcher für gerade diese API gibt, aber das Grundprinzip bleibt ja gleich)

Wenn du die Funktion unbedingt brauchst und das Programm ohne nicht geht, dann kann man die Funktion auch statisch einbinden ... siehe z.B. die Unit Windows, wo statische und dynamische Beispiele drin sind.


In deinem Beispiel wird die Funktion jedesmal bei jedem Aufruf geprüft und wenn noch nicht geladen, dann wird das erstmal gemacht, vor dem Aufruf.
Man kann die Funktions-Variable aber auch schon beim Programmstart (in einer eigenen Init-Prozedur, welche man aufruft) oder in Initialization laden.

[Benmik]

Vielen Dank!

Insgeheim hatte ich natürlich gehofft, einer von euch Könnern würde mal lässig was aus dem Handgelenk hier hin werfen, aber naja, Weihnachten ist vorbei, und hier wird ja viel Wert auf Eigenanstrengung gelegt ...
Ehrlich gesagt ist es nicht so sehr die Anpassung des Beispiels, die mir, glaube ich, nicht soviel Probleme bereiten würde, als vielmehr die Übersetzung der Datentypen, da ich von C++ keine Ahnung habe. Was für ein Datentyp ist zum Beispiel "hFindStream"? Ein Handle, also Cardinal?

Aber da habe ich doch diese nette Seite gefunden, die mir vermutlich weiterhelfen wird. Das Konzept der Eigenanstrengung scheint also nicht verkehrt zu sein (wenn mir auch Weihnachten lieber ist...)

[Benmik]

Wie vermutet sind es die Datentypen, insbesondere die Pointer, bei denen ich nicht weiterkomme.

Könnte mir vielleicht doch jemand helfen, wie ich mit Typumwandlungen, der eventuellen Initialisierung und dem Aufruf von LPCWSTR, LPDWORD und PWCHAR verfahren muss? Die Funktion selber scheint zu klappen, aber der Rückgabewert von "LinkName" ist Müll.
Ich habe Linkname als PWideChar deklariert und mit GetMem(LinkName, 256 * SizeOf(WideChar)) initialisiert, StringLength als LPDWORD mit GetMem(PDatLänge, SizeOf(DWORD)). Aber das funktioniert nicht und beim Beenden gibt es trotz FreeMem eine Schutzverletzung.
Vielleicht könnte mir doch jemand unter die Arme greifen.

[himitsu]

Bei PChars wird oftmals nur der Inhalt überschrieben und nicht der Variablenzeiger.

Den Speicher für die Variable mußt du vorher reservieren.

GetMemory, SetLength oder sonswie, jenachdem was für einen Speicher du nimmst.

z.B. kann man sich einen WideString oder UnicodeString nehmen, da via SetLength ausreichend Speicher/Zeichen reservieren und das dann via PWideChar gegastet an die Funktion übergeben, welche dann den Text dort reinschreibt.