Stapelverarbeitung bearbeitet nur die Hälfte

Deutsch
, ,
#1

Hallo,

ich migriere mit LibreOffice 7.0 über unten stehenden CMD-Code DOC-Dateien in DOCX (oder XLS nach XLSX u.a.).

For %f in (*.doc) do (
"C:\Program Files\LibreOffice\program\swriter.exe" --headless --convert-to docx --outdir /Dokumente/Outlook-Dateien_Dateiablagen/Test/Dat/Ausgabe %f
)

Die Zeilen gebe ich einzeln ein und bestätige nach jeder Zeile mit ENTER.

Es werden damit aber immer nur die Hälfte der Dateien migriert / verarbeitet, egal ob ich mit 2, 4 oder 8 Dateien teste. Dabei werden die Dateien willkürlich ausgewählt (also nicht die erste Hälfte oder die zweite Hälfte). Bei mehrfachem Versuchen sind es auch nicht immer die gleichen Dateien.

Wo liegt der Fehler?

Schönen Gruß

Uwe

#2

Mal abgesehen davon, dass ich nicht verstehe, wieso man von einem Fremdformat in eine anderes Fremdformat konvertieren will - kann man den Fehler sicher nicht analysieren, wenn man keine Idee von den Namensformaten (Umlaute, Leerzeichen, Sonderzeichen im Dateinamen enthalten…) hat. Es wäre daher hilfreich für eine Nachstellung des Problem eine kleine Liste von Dateiname zu erhalten.


> Die Zeilen gebe ich einzeln ein und bestätige nach jeder Zeile mit ENTER.

Das verstehe ich nicht. Das For... in (*.doc) do... Konstrukt arbeitet doch jede Datei, die es im aktuellen Verzeichnis findet, ohne jede weitere Benutzereingabe ab. Oder etwa nicht?

#3

Hallo Opaque,

danke für deine Antwort.

Mal abgesehen davon, dass ich nicht verstehe, wieso man von einem Fremdformat in eine anderes Fremdformat konvertieren will

Hintergrund ist die Langzeitarchierung von Dateiablagen. Hierfür teste ich derzeit Vorgehen zur Massen-Migration bestimmter Dateitypen. DOC ist nicht archivfähig, DOCX ist es zumindest als Übergangs- und stabileres Weiternutzungsformat geiegnet (das richtige Archivformat ist natürlich PDF/A). Eine Massen-Migration mittels Stapelverarbeitung (Batch) von DOC nach DOCX geht derzeit nur mit LibreOffice.

Es wäre daher hilfreich für eine Nachstellung des Problem eine kleine Liste von Dateiname zu erhalten.

Mein Fehler, hätte gleich angeben sollen, dass die Dateinamen zu Testzwecken gleich aufgebaut sind:
DOC_--1--ÄÖÜ-äöü-ß.doc bis DOC--8--_ÄÖÜ-äöü-ß.doc

#4

Das verstehe ich nicht. Das For… in (*.doc) do… Konstrukt arbeitet doch jede Datei, die es im aktuellen Verzeichnis findet, ohne jede weitere Benutzereingabe ab. Oder etwa nicht?

Das hatte ich so anderswo gelesen. Aber du hast recht, ENTER muss ich nicht jedesmal eingeben. Aber die Zeile müssen so bleiben (zumindest tut es nicht, wenn ich die Zeilen zu einer vereine).

Gruß

Uwe

#5

Testzwecken gleich aufgebaut sind: DOC_--1--ÄÖÜ-äöü-ß.doc bis DOC--8--_ÄÖÜ-äöü-ß.doc

[1] Aber das sind schon echte .doc Binärdateien? LibreOffice verläßt sich nämlich nicht auf die Endung einer Datei, sondern ermittelt den benötigten Importfilter anhand des Inhalts einer Datei (zumindest in der Regel).


[2] Und die `_` (Unterstriche) habe ich jetzt buchstäblich zu interpretieren oder als Platzhalter für Leerzeichen? Sorry für die pingeligen Nachfragen - aber ich habe zu viele Skripte geschrieben, bei deren Debugging es genau auf diese Kleinigkeiten ankam.
#6

zu [1]: ja, es sind echte Dateien. Ich habe eine Datei mit Word angelegt bzw. gespeichert und ein paar Mal kopiert. Sie sind also, abgesehen vom Dateinamen, identisch - der Fehler tritt unabhängig vom Dateiformat auf, ich habe mit DOC, DOCX, XLS, XLSX, und PPT getestet

zu [2]: die Unterstriche sind echte Unterstriche. Mit Leerzeichen im Dateinamen funktioniert die Stapelverarbeitung nicht.

#7

Hallo Opaque,

vielen Dank für deine Hilfe. Ja, das bringt mich weiter, es funktioniert, wie es soll!

Schönen Gruß

Uwe

#8

P.S. bei mir dauert es unter Windows nur 10 sek für 8 Dateien

#9

P.S. bei mir dauert es unter Windows nur 10 sek für 8 Dateien

Danke - hat mich veranlasst mal zu suchen, was meine virtuelle Maschine da so ausbremst (Microsoft Store-Installationsdienst ist Amok gelaufen).

#10

Hallo,

ich habe das nun mit folgender Dateiliste mal nachgestellt:

DOC_-_-_1_-_-_ÄÖÜ-äöü-ß.doc
DOC_-_-_2_-_-_ÄÖÜ-äöü-ß.doc
DOC_-_-_3_-_-_ÄÖÜ-äöü-ß.doc
DOC_-_-_4_-_-_ÄÖÜ-äöü-ß.doc
DOC_-_-_5_-_-_ÄÖÜ-äöü-ß.doc
DOC_-_-_6_-_-_ÄÖÜ-äöü-ß.doc
DOC_-_-_7_-_-_ÄÖÜ-äöü-ß.doc
DOC_-_-_8_-_-_ÄÖÜ-äöü-ß.doc

Dein Kommando hat zwei Probleme (unter Windows):

  1. Verwendung von swriter.exe anstatt nur soffice
  2. Die Klammerung () um das Kommando herum, was wohl die Ausführung der Konvertierungs-Befehle parallelisieren soll, aber zu einem Problem führt (Bin kein Windows-Spezialist und daher eher Laie in der Batch-Pro­gram­mie­rung unter Windows. Daher kann ich die Bedeutung von () nur aus den verursachten Folgen schließen)

(Genaugenommen produziert die Verwendung von swriter.exe denselben Fehler, wie die Verwendung der Klammerung () da swriter.exe nur ein Wrapper für soffice ist. Daher wird swriter.exe als Prozess sofort beendet sobald soffice gestartet ist, soffice.bin läuft aber im Hintergrund noch und die Schleife wird aber schon fortgesetzt. Der nächste soffice Start soll dann schon erfolgen, obwohl die Arbeit aus dem vorangegangen Schleifendurchlauf noch gar nicht beendet ist.)

Mit der Kommandozeile:

for %f in (*.doc) do "%ProgramFiles%\LibreOffice\program\soffice" --headless --convert-to docx --outdir "%HOMEPATH%\Documents\MassConversionOut" %f

erreicht man eine sequentielle Abarbeitung und dann hat das bei mir funktioniert, wobei ich das unter Windows als extrem träge empfinde. Unter Linux ging das in 2 Sekunden meine 8 Dateien zu konvertieren, während das unter Windows 10 weit mehr als 1 Minute gedauert hat.

Getestet mit LibreOffice

Version: 7.0.5.2 (x64), Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a
CPU threads: 1; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: en-US (en_DE); UI: de-DE, Calc: threaded

Ich hoffe das bringt Dich ein wenig weiter.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.