Lange Dateinamen und ExpandFilename

Gausi · Verfasst: So 11.01.09 21:39

Folgendes:

Ich möchte zu einem Dateinamen den relativen Pfad bzgl. eines anderen Ordners bestimmen, und später daraus wieder den vollständigen Pfad zurückbekommen.

Das geht ja so:

markieren

Delphi-Quelltext

1:	RelativerPfad := ExtractRelativePath(BaseName, VollstaendigerDateiname);

Beispiel: Ich möchte in einer Datei Basename := 'd:\Playlists\test.m3u' den relativen Pfad zu VollstaendigerDateiname := 'd:\Artist\Album\Lied.mp3' reinspeichern (Ergebnis ist '..\Artist\Album\Lied.mp3').

Mit Hilfe von

markieren

Delphi-Quelltext

1:
2:
3:
4:

// für Tests evtl. Verzeichnis erzwingen - wenn man die m3u-Datei laden kann, ist es ja auf jeden Fall da ;-)
ForceDirectories(ExtractFileDir(Basename));
SetCurrentDir(ExtractFileDir(Basename));
ExpandFilename(RelativerPfad));

bekommt man wieder den vollständigen Namen zurück. Soweit ok.

Folgendes Problem gibt es bei langen Dateinamen:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

VollstaendigerDateiname := 'd:\01234567890123456789012345678901234567890123456789' +
'01234567890123456789012345678901234567890123456789\' +
'01234567890123456789012345678901234567890123456789' +
'01234567890123456789012345678901234567890123456789\test.mp3'; // 213 Zeichen, also weniger als MAXPATH!
// Dieser Basename funktioniert
Basename := 'd:\01234567890123456789\test.m3u';

// Dieser nicht:
Basename := 'd:\01234567890123456789012345678901234567890123456789\test.m3u';

Der ermittelte relative Dateiname ist in beiden Fällen korrekt (und ist in beiden Fällen derselbe), aber der umgekehrte Weg geht beim zweiten nicht mehr. Es gibt wohl Probleme, wenn die Summe der beide Längen größer als MAXPATH wird, aber das ist ja irgendwie sinnfrei, oder?

Ich verwende normal Delphi 7 Personal, wenn man das ganze mit den TNT-Varianten der Funktionen durchführt, gibt es dieselben Probleme, mit Delphi 2007 gibt es das Problem auch.

Jemand eine Idee, wie man das beheben oder umschiffen kann?

Edit: "Geht nicht" heißt hier einfach: Das Ergebnis ist leer und/oder enthält Datenmüll.

_________________
We are, we were and will not be.

jaenicke · Verfasst: So 11.01.09 23:05

Ich würde statt ExpandFilename lieber PathCombine benutzen, da du dann nicht das aktuelle Verzeichnis berücksichtigen bzw. setzen musst:
www.swissdelphicente...showcode.php?id=1956
Das ändert aber am Problem nichts.

Die Erklärung, warum beides zusammen nicht länger als MAXPATH sein darf, könnte sein, dass die Pfade konkateniert und dann die ..\ "gekürzt" werden. Dass diese Einschränkung nicht dabei steht, ist aber nicht schön.

Da wird wohl nur eine manuelle Korrektur möglich sein...
Zum Beispiel in der Art:
Solange ..\ am Anfang des relativen Pfades steht jeweils einmal ExtractFileDir auf BaseName anwenden und das aktuelle ..\ löschen. Da ExtractFileDir den Pfad ohne den Backslash zurückgibt, reicht das bereits.

Eine "offizielle" Lösung habe ich jetzt auch nicht gefunden.

Gausi · Verfasst: Mo 12.01.09 22:04

Irgendwo gibt es da noch eine Möglichkeit, aber die habe ich noch nicht ganz raus. Wenn ich meine m3u mit Winamp öffne, gibt es da auch das Problem mit dem Datenmüll.
Wenn ich die betreffenden mp3-Dateien in die Winamp-Playlist einfüge und die Liste in einem "problematischen Verzeichnis" abspeichere, klappt es mit Winamp. Die Pfade werden dann anders gespeichert (ohne die ..\..\ am Anfang, sondern beginnend mit \).
Erstaunlicherweise wird auch diese Playlist von meinem Player korrekt geladen.

Die Lösung dürfte also nicht bei einem ändern von ExpandFilename, sondern bei ExtractRelativePath liegen. Mal sehen, wie ich das hinbekomme.

_________________
We are, we were and will not be.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme