Dateisystem: Non-PChar-Dateinamen und WinAPI

[himitsu]

Also erstmal vorweg:

Ich hab hier eine alte Festplatte (FAT32), wo der IDE-Controler (Mainboard) durchgedreht ist
und willkürlich Integerwerte im unterem Bereich (bis 255) in den Datenstrom reinschmuggelte ... also quasi viele #0en auf der Platte und auch im Dateisystem verteilte.

Checkdisk erkennt dieses allerdings nicht als Fehler und behebt es demnach nicht.
Auch wenn ich weiß, wie ich das am Dateisystem vorbei umgehen bzw. den Fehler manuell beheben kann.
Also sind praktisch einige Dateien nicht zugreifbar, da beim Auslesen/Zugreifen alles ab der #0 ja abgeschnitten wird ... PChar halt.

Die Platte bzw. der Datenfehler ist schon älter und ich hab mir das eigentlich nur noch als Testobjekt aufgehoben, also ich brauch jetzt keine Tipps zum Reparieren. :zwinker:

Nun ist mir aber grad eben zufällig aufgefallen, das FindFirstFile mir unter Umständen mir dennoch den kompletten Dateinamen liefert.

Nur kann ich ja nun nicht einfach per DeleteFile, MoveFile oder CreateFile drauf zugreifen, da diese ja bekanntlich die #0en im Dateinamen nicht mögen.

Nun die Frage:
kennt wer zufällig passende Funktionen (Win2k bis Seven), welchen man auch solche Dateinamen übergeban kann?
(bei der Registry weiß ich z.B., daß es solche Funktionen gibt)

Aber wenn, dann wäre es nicht schlecht, wenn diese Funktionen relativ zuverlässig funktionieren.

[mirage228]

Die internen NT-Funktionen könnten evtl. gehen. Sowas wie NtDeleteFile...

Viele Grüße

[himitsu]

Ohhh, von den Funktionen hatte ich doch schonmal was gehört, :shock:
aber mir war so, als wenn die auch PChar genutzt hätten. :oops:

Aber sieht gut aus :thumb:
Mal sehn ob ich demnächst etwas Zeit finde und was sich damit alles machen läßt.

[Luckie]

Da die Windows API in C geschrieben ist und C nur Charackterarrays kennt, habe ich da wenig Hoffnung, dass das funktioniert.

[himitsu]

einige der netten Nt...- bzw. Zw...-APIs nutzen einen UNICODE_STRING mit Längenangabe

und so wie es aussieht, hab ich grad noch 'nen teilweisen Ersatz für FindFirstFile gefunden, obwohl man diesem eh schon den vollen Namen entlocken kann (wenn man so Einiges beachtet :nerd: ),
welcher aber schneller sein dürfte/könnte.

bei FindFirstFile braucht man ja ganz schön Zeit, bis ein größeres Verzeichnis eingelesen ist.

[himitsu]

Also einen Tree, welcher mit allen Partitionen gefüllt ist, selbst die nicht gemounteten
und wo auch die "defekten" Dateien mit angezeigt werden, war ja noch leicht. :angel:

Aber dieses NtDeleteFile will einfach nicht löschen :cry:

Delphi-Quellcode:

Procedure TForm1.delete1Click(Sender: TObject);
  Var S2: WideString;
    S: UNICODE_STRING;
    O: OBJECT_ATTRIBUTES;
    E: NTSTATUS;

  Begin
    If Tree1.GetFirstSelected = nil Then Exit;
    S2 := GetFullName(Tree1.GetFirstSelected);
    S.Length        := Length(S2) * 2;
    S.MaximumLength := MAX_PATH * 2;
    S.Buffer        := PWideChar(S2);
    O.Length                   := SizeOf(OBJECT_ATTRIBUTES);
    O.RootDirectory            := 0;
    O.ObjectName               := @S;
    O.Attributes               := 0;
    O.SecurityDescriptor       := nil;
    O.SecurityQualityOfService := nil;
    E := NtDeleteFile(O);
    ShowMessage(SysErrorMessage(E and $0FFFFFFF));
  End;

S bzw. S2 enthalten z.B. einen String wie

Delphi-Quellcode:

S2 := '\\?\Volume{7172b2a6-ae53-11dd-853d-806d6172696f}\Da'#0'ài_Suchen.exe'

und das nicht gelöscht wird, liegt nicht an der #0, denn es geht bei allen Dateien nicht.

auch sowas mag die Funktion nicht :?

Delphi-Quellcode:

S2 := '\\.\S:\Da'#0'ài_Suchen.exe'
S2 := 'S:\Da'#0'ài_Suchen.exe'

die aktuelle Fehlermeldung ist (mit dem obrigem Code)

Zitat:

Windows kann den Netzwerkpfad nicht finden. Überprüfen Sie, dass der Netzwerkpfad korrekt ist und dass der Zielcomputer nicht ausgelastet oder ausgeschaltet ist. Falls dies nicht der Fall ist, sollten Sie sich an den Netzwerkadministrator wenden

es gab auch schon Andere ... weiß jetzt nur nimmer wie die genau lauteten :nerd: