[XE] Bug in TDirectory.Copy, gibts schon einen QC eintrag?

[Memnarch]

Moin,
Habe einen Bug in TDirectory.Copy festgestellt. Habe nachgeguckt ob es bereits einen QC-Eintrag gibt, schien aber nicht so(vllt hab ich auch falsch gesucht, kann das jemand bestätigen?).
Könntet ihr vllt einmal nachgucken, ob der Bug in einer der Folgeversionen (xe2-xe7, jenachdem was ihr habt) gefixxt wurde?

Der Bug:
Normalerweise kopiert TDirectory.Copy die Ordnerstruktur von Source nach Destination, undzwar rekursiv.
Wenn ich folgenden pfad habe:
C:\Foo\FooB\File.txt

kann ich folgendes machen um alles zu kopieren:

TDirectory.Copy('C:\Foo', 'D:\Target') Bei folgendem geht es aber nicht, der Ordner FooB ist dann nämlich leer:

TDirectory.Copy('C:\Foo\', 'D:\Target') Kaputt geht es nur, weil am Ende ein Backslash angefügt wurde. In der Methode gibt es einen aufruf zu StuffString, dort möchte man den SourcePfad vom kompletten Pfad am Anfang abschneiden(also praktisch soetwas wie ExtractRelativePath)

Die Länge des SourceDir-Strings wird allerdings falsch berechnet, nämlich so:

Length(SourceDir) + Length('\') Es wird also immer ein Backslash dazugerechnet, hat der Pfad also bereits eines, geht der erste Buchstabe des relativen Pfades verloren. TFile.Copy schlägt dann fehl(was auch nicht zurückgegeben wird). Wahrscheinlich wäre

Length(IncludeTrailingPathDelimiter(SourceDir)) besser gewesen.

Jedenfalls: Gibts diesen Bug in den folgeversionen noch oder vllt schon einen QC Eintrag, den ich nur übersehen habe?

MFG
Memnarch

[Sir Rufo]

Ich sehe das gar nicht als Bug an.

Delphi-Quellcode:

TDirectory = class
...
class procedure Copy(const SourceDirName, DestDirName: string); static;
...
end;

Da steht also etwas von SourceDirname und DestDirName und nicht etwa SourcePath oder DestPath .

Und ein Path zeichnet sich immer durch einen PathDelimiter am Ende aus und ein Directory durch einen fehlenden PathDelimiter am Ende.

Code:

Path = C:\Foo\
Directory = C:\Foo

Wenn du also jetzt statt eines Directory einen Path übergibst, dann hast du einfach einen falschen Wert übergeben, erwartest aber, dass es trotz falscher Werte richtig funktioniert.

[Faxe]

Aber die Hilfe redet von Pfaden:

Use Copy to copy a directory and its contents from a given path to another path.

SourceDirName
The path of the source directory that will be copied.

DestDirName
The destination path to which the directory will be copied.

[Sir Rufo]

Zitat von Faxe:

Aber die Hilfe redet von Pfaden:

Use Copy to copy a directory and its contents from a given path to another path.

SourceDirName
The path of the source directory that will be copied.

DestDirName
The destination path to which the directory will be copied.

Ja, auch bei Emba gibt es Menschen, die den Unterschied zwischen einem Verzeichnis und einem Pfad nicht kennen.
Noch schlimmer ist es allerdings, dass es auch Entwickler bei Emba gibt, die den nicht kennen und Verzeichnis schreiben und Pfad meinen, bzw. Pfad schreiben und Verzeichnis meinen.

[Uwe Raabe]

Also bei XE2-XE7 wird unterschieden, ob das letzte Zeichen ein Path-Separator ist oder nicht.

[Sir Rufo]

Zitat von Uwe Raabe:

Also bei XE2-XE7 wird unterschieden, ob das letzte Zeichen ein Path-Separator ist oder nicht.

Ähm, du meinst sicher TPath.DirectorySeparatorChar und nicht TPath.PathSeparator

[Uwe Raabe]

Zitat von Sir Rufo:

Zitat von Uwe Raabe:

Also bei XE2-XE7 wird unterschieden, ob das letzte Zeichen ein Path-Separator ist oder nicht.

Ähm, du meinst sicher TPath.DirectorySeparatorChar und nicht TPath.PathSeparator

Nein, ich habe ja auch gar nicht TPath.PathSeparator erwähnt.

Die Abfrage heißt

        if not TPath.IsPathSeparator(Ch) then

was zwar in der Nomenklatur obigen Schluss zulassen würde, aber ganz anders implementiert ist.

[Sir Rufo]

Zitat von Uwe Raabe:

Zitat von Sir Rufo:

Zitat von Uwe Raabe:

Also bei XE2-XE7 wird unterschieden, ob das letzte Zeichen ein Path-Separator ist oder nicht.

Ähm, du meinst sicher TPath.DirectorySeparatorChar und nicht TPath.PathSeparator

Nein, ich habe ja auch gar nicht TPath.PathSeparator erwähnt.

Die Abfrage heißt

        if not TPath.IsPathSeparator(Ch) then

was zwar in der Nomenklatur obigen Schluss zulassen würde, aber ganz anders implementiert ist.

Oh, da stimmt die Namensgebung auch nicht so richtig überein ...

[Uwe Raabe]

Zitat von Sir Rufo:

Oh, da stimmt die Namensgebung auch nicht so richtig überein ...

Nicht nur das - die Implementation ist auch buggy: Endet der Pfad mit einem Doppelpunkt, wird fälschlicherweise nämlich kein Backslash eingefügt. Aber wer kopiert auch schon ganze Laufwerke, nicht wahr?

[Memnarch]

Naja, alles was nicht mit einem Backslash endet scheint eher ein Dateiname zu sein(Soweit sehen es zumindest z.B. die Winapi funktionen).
Und auch ExtractRelativePath würde das letzte Element als Dateiname nehmen, wenn "\" fehlt.

Und zumindest hätte ich bei der Exception-Politik erwartet, dass es dann mit einer Exception in die binsen geht. Zumindest den Resultwert von TFile.Copy hätte man verwerten können. Es kann schließlich auch nicht sein, dass eine funktion ohne Probleme durchrennt und dann nicht funktioniert hat.