SQX (Selfextract-Entpackproblem)

[bert breuer]

Hallo !


Bin eben von einem Kollegen darauf aufmerksam gemacht worden, dass meine mit SQX erzeugte Multivolumen-Selfextractdatei nicht ausführbar wäre (hatte sie ihm per Mail zugesandt).

Nach ausführlichem Test bin ich auch der Ursache auf den Grund gekommen. In der Tat wird der "Fehler 28058 in setup.exe" vom Selbstentpacker zurückgegeben und ein Entpacken ist somit nicht möglich.


Name der Ursprungsdatei: setup.exe (30 MB)
Name der erzeugten Selfextractordatei 1: setup.exe (10 MB)
Name der erzeugten Selfextractordatei 2: setup.001 (10 MB)
Name der erzeugten Selfextractordatei 3: setup.002 (10 MB)


Ursache hierfür ist folgendes:
Da der Name der Ursprungsdatei hier gleich dem Namen der erzeugten (und auch vom SQX-PlugIn vorgeschlagenen Selbstenpackers ist), tritt beim späteren Entpacken logischerweise ein Dateinamenskonflikt auf. Das erzeugte Selbstentpackende Archiv hat inhaltlich zwar keinen Fehler, jedoch kann der Entpackvorgang nicht vollendet werden, weil wie ja schon eben erwähnt, der Dateiname "setup.exe" in dem Fall doppelt vergeben wurde.


1. Frage, ist dieses Verhalten bekannt, oder gar gewollt!?

2. Sollte nicht in einem solchen Fall das SQX-Plugin diesen Konflikt schon im Vorfeld erkennen, bzw. dann auch einen anders lautenden Archivnamen für die Selbstextrahierende Datei vorschlagen!?


P.S. Sicherlich kann man händisch das Problem vorher entschärfen, wenn man kurz vorm Packen noch schnell den Dateinamen umbenennt, aber so etwas sollte doch wohl eher Aufgabe des PlugIns sein. Zumal ja nicht jeder Anwender dies im Vorfeld erkennen kann, bzw. damit vertraut sein wird. Denn erst beim späteren Entpacken tritt ja dann das Phänomen auf und dann ist meist schon die Datei/en verschickt...

Gruß Bert

[Lefteous]

Hallo,

Du hast natürlich recht, dass das Plugin beim Erstellen eine Warnung ausgeben könnte. Das Problem ist jedoch, dass es nach dem Packen eine Grauzone gibt, nämlich die bis zum Entpacken. Was dazwischen passiert, kann das Plugin nicht steuern. Wenn der Benutzer hier wieder einen problematischen Dateinamen wählt, so tritt das Problem wieder auf. Dein Lösungsvorschlag ist also im Grunde genommen nur eine Heuristik, die manchmal, aber sicher nicht immer helfen wird. Letztlich kann nur das selbstentpackende Archiv selbst verhindern, dass eine Datei, die genauso heißt, in das gleiche Verzeichnis entpackt wird. Das macht es aber nicht und daran kann ich auch nichts ändern. Soweit ich weiß wurde hier keine komplexe Behandlung solcher Situationen eingebaut, um die selbstentpackenden Archiven möglichst klein zu halten.

Nebennei erwähnt existiert das Problem für alle bekannten Packer, also auch Standalone-Programme wir WinRAR oder 7zip. Das ist zumindest mein letzter Stand.

Das das Problem auffällig häufig in Zusammenhang mit meinem Plugin erläutert wird, läßt darauf hoffen, dass es doch recht häufig eingesetzt wird. Ich werde mal schauen, ob ich die Pluginseite dieser Problems lösen kann.

p.s.: Eine Suche nach "28058" hätte auf den deutschsprachigen TotalSQX-Thread geführt, wo das Thema auch bereits schon mal mit den oben aufgeführten Argumenten diskutiert wurde.

[bert breuer]

@Lefteous

Ja da hast Du natürlich Recht, habe wirklich nicht die Suche bemüht. Aber wohl eher aus dem Grunde, weil ich's ziemlich schnell "melden" wollte


Klar, wenn der "Endnuzter" wiederum durch Zufall einen identischen Namen seinerseits eingibt, ensteht das Phänomen wieder.
Aber andererseits wäre es zumindest beim Erstellen sehr sinnvoll, wenn kurz abgescheckt wird, ob 2 identische Dateinamen vorliegen. Ich denke, das wäre doch schon die halbe Miete

Dürfte doch eigentlich kein größerer Programmieraufwand sein, aber das liegt natürlich in Deinem Ermessen ob Du da was ändern möchtest, wollte es halt nur mal ansprechen


P.S. Wie gesagt, inhaltlich ist alles korrekt gepackt worden.


Gruß Bert

[Dalai]

Nebennei erwähnt existiert das Problem für alle bekannten Packer, also auch Standalone-Programme wir WinRAR oder 7zip.

Wenn ich mit WinRAR eine EXE packen will und mich dazu entschließe, ein SFX-Archiv zu machen, wird automatisch .sfx vor die Erweiterung .exe ergänzt. WinRAR geht dem Problem beim Packen also durchaus aus dem Weg.

Beispiel: setup.exe wird als SFX gepackt -> setup.sfx.exe kommt raus.

MfG Dalai

[Lefteous]

2Dalai

Wenn ich mit WinRAR eine EXE packen will und mich dazu entschließe, ein SFX-Archiv zu machen, wird automatisch .sfx vor die Erweiterung .exe ergänzt. WinRAR geht dem Problem beim Packen also durchaus aus dem Weg.

Meine Aussage bezog sich auf den Entpackerteil. Ich hatte das mal getestet, als das Problem schon mal diskutiert wurde.

[bert breuer]

Nebennei erwähnt existiert das Problem für alle bekannten Packer, also auch Standalone-Programme wir WinRAR oder 7zip.

Wenn ich mit WinRAR eine EXE packen will und mich dazu entschließe, ein SFX-Archiv zu machen, wird automatisch .sfx vor die Erweiterung .exe ergänzt. WinRAR geht dem Problem beim Packen also durchaus aus dem Weg.

Beispiel: setup.exe wird als SFX gepackt -> setup.sfx.exe kommt raus.

MfG Dalai

Hallo Dalai
Ja das wäre doch eine Vorgehensweise die man in Betracht ziehen könnte und sicherlich allgemein Zustimmung findet. Zudem geht man damit ja unschönen Fehlermeldungen aus dem Weg die evtl. später beim Entpacken auftreten. Das sollte doch eigentlich auch im Interesse des Authors (also in diesem Fall Lefteous) sein.

Von daher würde dieser Lösungsansatz meine volle Zustimmung finden

Gruß Bert

[Lefteous]

Auf eines möchte ich noch hinweisen: Die Pluginschnittstelle sorgt ja für eine einheitliche Oberfläche für alles Packerplugins. Auch in diesem Fall wäre es möglich das Problem auf Schnittstellenebene zu lösen, denn diese vergibt den Dateinamen und weiß welche Dateien hinzugefügt werden sollen. So hätten alle Packerplugins etwas davon. Das müsste dann aber Ghisler einbauen.

[bert breuer]

Deine Idee, dass alle Packer-PlugIns etwas davon haben wäre natürlich der Einzellösung klar vorzuziehen

Dem Anwender wäre es wohl egal, wie das Problem letztendlich gelöst werden würde. Hauptsache der unschöne Makel findet ein Ende


P.S. Dann hoffen wir mal, dass Christian sich zum Thema äußert, bzw. wie er das sieht. Jedenfalls wäre es schön, wenn sich diesbezüglich wirklich was ändert.

Gruß Bert

[ghisler(Author)]

Der Name wird beim Packen so gewählt:
1. Mehrere Dateien markiert -> Verzeichnisname.zip
2. Nur 1 Datei/1 Verzeichnis markiert -> Dateiname.zip

Normalerweise will man ja keine ZIP-Dateien erneut packen, deshalb gibt es da kein Problem. Beim Packen als selbstentpackendes Archiv wird einfach die Endung des Packers durch exe ersetzt. Dies macht natürlich nur so lange keine Probleme, wie man nicht eine einzelne EXE-Datei packt. In diesem Fall wäre es in der Tat sinnvoll, den Namen zu ändern - das überlasse ich aber lieber dem User.

[bert breuer]

In diesem Fall wäre es in der Tat sinnvoll, den Namen zu ändern - das überlasse ich aber lieber dem User.

Das ist ja schön und gut (und die allereinfachste Lösung), dies dem Anwender zu überlassen. Nur ändert das nichts an der Situation, denn man muß sich auch die Frage gefallen lassen, welchem Anwender dies überhaupt während des Packvorgangs bewußt ist, nämlich kaum jemandem!!! - Vor allem, da während des Packvorgangs keinerlei Meldung oder gar Fehlermeldung ausgegeben wird. Daher merkt der Anwender auch nichts und wird später eine "böse" Überraschung erleben, oder derjenige der die gepackte Datei als Empfänger bekommt.

Ehrlich gesagt, kann ich nicht so ganz nachvollziehen warum man hier einem im Prinzip recht kleinen Problem, mit ebenso geringem Programmieraufwand, so gezielt aus dem Weg geht!? - Man brauch doch nur für Fälle einer Komprimierung mit EXE'en ein "sfx" mit in den Dateinnamen zu geben. Das kann doch wirklich nicht die Welt an Programmieraufwand sein.

P.S. Wie Dalai schon anmerkte, hat WinRAR dieses Problem erkannt und dem einen Riegel vorgeschoben. Warum also nicht hier?



Gruß Bert