Extrem langen Pfad kürzen, Result leer?

[himitsu]

MAX_PATH ist der komplette "Pfad", inkl. Datei-/Verteichnisname, Verzeichnisse, Laufwerk und der letzten #0.

[a.def]

Kann man dementsprechend abschließend festhalten, dass wenn die Länge Pfad sPathXYZ > MAX_PATH ist, man ihn am besten aus der Verarbeitung raushält um Fehler zu vermeiden?

[Aviator]

Also direkt über die Win API kann man bis Windows 8.1 nur Pfade mit der Länge von MAX_PATH kopieren. Es gab aber die bereits erwähnte Alternative mit \\?\ um Pfade zu kopieren die länger sind als MAX_PATH. Probiert habe ich das selbst nie und kann daher auch keine Lösung anbieten. Ab Windows 10 (ab einem speziellen Build soweit ich weiß) wurden die WinAPI Funktionen angepasst sodass sie Pfade bis 2^15 Zeichen verarbeiten können.

[Dalai]

Zitat von Aviator:

Also direkt über die Win API kann man bis Windows 8.1 nur Pfade mit der Länge von MAX_PATH kopieren. Es gab aber die bereits erwähnte Alternative mit \\?\ um Pfade zu kopieren die länger sind als MAX_PATH.

... was auch über die WinAPI erfolgt - insofern widerspricht der zweite Satz dem ersten .

Probiert habe ich es selbst auch nie, aber da ich weiß, dass Total Commander mit Pfaden länger 256 Zeichen umgehen kann (geht IIRC bis 1024) und der natürlich mit der WinAPI arbeitet, kann ich mit Sicherheit sagen, dass es funktioniert. Nur mal ein Beispiel: CopyFileEx:

Zitat:

In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?\" to the path.

Es muss also die Unicode-Variante der Funktion gerufen werden, der Prefix muss vorhanden sein, und natürlich darf man den String nicht auf MAX_PATH kürzen. Und wie ich schon sagte können möglicherweise nicht alle API-Funktionen mit den überlangen Pfaden umgehen; LoadImage, LoadIcon fallen mir da spontan ein.

Grüße
Dalai

[Aviator]

Zitat von Dalai:

... was auch über die WinAPI erfolgt - insofern widerspricht der zweite Satz dem ersten .

Ja ok. Wie gesagt ich habe es nie probiert und wusste es daher nicht. Aber logisch wäre es schon. Nur muss man dann scheinbar spezielle Funktionen aufrufen. Sind das alle mit "Ex" am Schluss?

[Dalai]

Zitat von Aviator:

Nur muss man dann scheinbar spezielle Funktionen aufrufen.

Nicht spezielle Funktionen, nur der Pfad im entsprechenden Parameter ist anders.

Zitat:

Sind das alle mit "Ex" am Schluss?

Nicht nur. Für GetShortPathName schreibt MS denselben Satz wie für CopyFileEx, diese Funktion soll also auch damit umgehen können.

Grüße
Dalai

[HolgerX]

Hmm..

Damit geht es:

Delphi-Quellcode:

// nur wenn NtfsDisable8dot3NameCreation=0
function GetShortName(sLongName: WideString): WideString;
var
  sShortName: WideString;
  nShortNameLen: Integer;
begin
  sShortName := '';
  nShortNameLen := 0;
  nShortNameLen := GetShortPathNameW(PWideChar(sLongName), nil, nShortNameLen);
  if nShortNameLen > 0 then begin
    SetLength(sShortName, nShortNameLen);
    nShortNameLen := GetShortPathNameW(PWideChar(sLongName), PWideChar(sShortName), nShortNameLen);
    if (nShortNameLen = 0) then
      raise Exception.Create(SysErrorMessage(GetLastError));
    Result := sShortName;
  end else begin
    raise Exception.Create(SysErrorMessage(GetLastError));
  end;
  Result := sShortName;
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  s : Widestring;
begin
  s := '\\?\D:\0123456789\11111111111111111111111111111111111111111111111111';
  s := s + '\22222222222222222222222222222222222222222222222222';
  s := s + '\33333333333333333333333333333333333333333333333333';
  s := s + '\44444444444444444444444444444444444444444444444444';
  s := s + '\55555555555555555555555555555\Datei.txt';

  Edit1.Text := GetShortName(s);  // \\?\D:\012345~1\111111~1\222222~1\333333~1\444444~1\555555~1\Datei.txt
end;

Selbst unter Delphi 6

Bedingt aber, das NtfsDisable8dot3NameCreation=0 gesetzt ist, eventuell VOR dem Erzeugen der Verzeichnisse und der Datei.