Bug mit Multirename & Regexp

[habla]

Hier eine Regexp, die das Multi-Rename-tool abstürzen läßt. Regexp-option muß dazu aktiv sein. Man kann Totalcmd dann nur noch über den Taskman schließen.

(-?)[.+]{0,} [.+]

Abgestürzt ist mir das Ganze, als ich {0,} eingefügt habe. Totalcmd war direkt bei der zweiten geschwungenen Klammer weg. (Der Ausdruck macht an sich nicht viel Sinn, das war in der Mitte von einem Test.) Könnte entweder ein TotalCMD oder ein Regexp-Bug sein.

[Sheepdog]

(-?)[.+]{0,} [.+]
Könnte entweder ein TotalCMD oder ein Regexp-Bug sein.

Weder noch, wie man hier sieht, geht das ganze wunderbar. Da muss wohl noch etwas anderes den Crash ausgelöst haben.

sheepdog

[habla]

So, bei mir tritt es auch nicht mehr auf. Komisch. Ich hab das 3-4x ausprobiert, ging zuverlässig ^^ Wenn ich alle Bedingungen zusammenbekommen sollte post ichs nochmal ;)

[ghisler(Author)]

Vielleicht tritt es nur bei ganz bestimmten umzubenennenden Dateinamen auf?

[habla]

Hallo Herr Ghisler,

es trat an genau den gleichen Dateinamen einen Tag später NICHT mehr auf. Aber kurioserweise hatte ich genau diesen Absturz gestern wieder, bei einem leider nicht mehr nachvollziehbaren Beispiel. Was beiden Fällen gemeinsam war: Ich habe mit den im ersten Post dargestellten Zeichen jeweils eine längere Zeit in der S&R-zeile herumprobiert. Dabei bin ich immer mal wieder mit ESC aus dem Multirename raus (die aktuelle Zeile geht ja nicht verloren dabei), um ein paar andere Testdateien zusätzlich auszuwählen. Irgendwann "freezt" der TotalCmd dann direkt bei der Eingabe von Zeichen in der S&R-Zeile. Ich habe übrigens bei diesen Tests nie Dateien wirklich umbenannt. Die Dateien, an denen ich umbenenne, sind pdf-, doc- und andere textfiles, bei denen (teilweise mehrere) Autoren, Titel und Untertitel jeweils mit "-" "&" oder "," und natürlich " " getrennt sind. Wenn sie wollen, schicke ich ihnen gern ein Zip mit Nullbyte-Dateien von einem Verzeichnis zu, in dem es aufgetreten ist.

Alles in allem tritt dieses Problem leider (oder zum Glück) eher selten auf... genau reproduzieren kann ich es atm nicht.

[ghisler(Author)]

Falls Sie einen Weg finden, das Problem zu reproduzieren, würde mir das sehr weiterhelfen!

[habla]

So, sieht so aus als könnte man das Verhalten doch reproduzieren. Nach einigem Probieren habe ich festgestellt, das ich mich in meinem allerersten Beitrag schlicht verschrieben habe

Anyway, unter folgendem Link
http://rapidshare.de/files/7061731/TCregexp-test.rar.html

ist ein Archiv mit ein paar Dateinamen, mit denen man das nachvollziehen kann. Folgendene RegExp sollt den Absturz verursachen:

(.+){0,}<leer> (Wobei <leer> für ein Leerzeichen steht.)

Durch etwas rumprobieren bin ich darauf gekommen, das es sich um eine Schleife zu handeln scheint. Folgender Ausdruck verlangsamt das Umbenennen, anstatt den TC ganz zu stoppen:

(.+){1,7}<leer>

Man merkt hier deutlich, das jedes grafische Update (z.B. Klick auf eine andere Datei der Liste) länger dauert, weil TC damit beschäftigt ist die RegExp upzudaten. Es empfiehlt sich vielleicht, mit den Werten in den geschwungenen Klammern zu spielen, um ein Gefühl für das Verhalten zu bekommen.

Wieso das jetzt auftritt... {0,}<leer> nach dem normalen (.+) ist nicht wirklich sinnvoll... zuerst "Mindestens ein Mal" (.+), gefolgt von "Null Mal"... das scheint die Engine etwas zu verwirren, so zumindest meine Vermutung als Nicht-Programmierer. (Obwohl ich da natürlich gänzllich falsch liegen kann.)

Als letztes noch, ich arbeite auf einem antiken Athlon800, gut möglich daß das Problem auf schnelleren Maschinen gar nicht in dem Maße auftritt wie bei mir. Falls das der Fall sein sollte, vielleicht noch mal probieren mit (?-g)(.+){0,} (.+) Das ist der Originalausdruck, der mir (Einbildung?) etwas langsamer zu sein scheint als die beiden obigen Versionen.

Alles Gute

Christian

[ghisler(Author)]

Danke für die Beispieldateien, damit kann ich es nun auch reproduzieren! Ich werde mir das mal in einem Debugger ansehen.