InDesign: Nach Absturz sind etliche Textfelder einfach leer … ?

[Diwarnai]

2020er iMac mit aktuellem OS, aktuellem Adobe CC, FontCaches gelöscht. Zuweilen stürzt InDesign ab, Dokument mit 96 Seiten. Nach dem Wiederherstellen sind etliche Textrahmen leer, auch welche, die an dem Tag gar nicht bearbeitet wurden. Irgendwelche Ideen, was da los sein könnte?

 

[Martin Schulz]

Den guten, alten Als-IDML-speichern-und-wieder-öffnen-Workaround hast Du sicher schon probiert, oder? Ansonsten hatten wir in jüngster Zeit auch immer mal wieder ganz rätselhafte InDesign-Abstürze bei ausgewählten (gern seitenstarken) Dokumenten mit vergleichbarer Hardware-Umgebung. Da half – so simpel das klingt – häufig, das Dokument mit einem anderen Rechner aufmachen und von als neue Datei speichern. 

[Diwarnai]

Als idml wird hin und wieder exportiert und neu geöffnet, aber wohl zu selten. Mit einem anderen Rechner zu öffnen ist eine gute Idee, werd ich mal schauen, ob das was hilft.

[Sebastian Nagel]

vor 5 Stunden schrieb Diwarnai:

Als idml wird hin und wieder exportiert und neu geöffnet, aber wohl zu selten. Mit einem anderen Rechner zu öffnen ist eine gute Idee, werd ich mal schauen, ob das was hilft.

Vielleicht etwas falsch verstanden: manchmal hilft es auch noch, das bereits defekte INDD nochmal als IDML zu speichern und wieder zu öffnen.

 

Auch ein Versuch wert: die so erzeugte IDML mal versuchen in Affinity Publisher zu öffnen und sehen was der dabei ausgibt ... da ist dann kein leicher Weg zurück zu Indesign möglich, aber vielleicht können so Texte geborgen werden.

 

Auch las ich schon von Fällen, wo der Adobe-Support noch was machen konnte (andere Rechnerplattform, andere Version, Debugging, Wissen um die Dateistruktur, ...).

 

Hier wohl nicht zielführend: In Fällen wo die Bildschirm-Anzeige einer Seite einen Absturz beim öffnen oder beim vorbeiscrollen verursacht, gibt es auch Scripte, die das INDD "blind", d.h. ohne Anzeige, öffnen, und gleich als IDML speichern – dabei werden Vorschauen etc. entfernt und beim Öffnen neu generiert, oft behebt das solche Probleme.

[Diwarnai]

Das indd ist ja (auf den ersten Blick?) nicht defekt, es fehlen halt nur Texte in manchen Textfeldern. Da ist dann einfach nur ein Return drin, sonst nichts. 

Auch wenn’s eigentlich völlig albern ist – ich hab der Kollegin dann den Tipp gegeben, alle 5 oder 10 Minuten unter einem anderen Namen abzuspeichern, dann geht wenigstens nicht arg viel Arbeit verloren, wenn ID wieder abstürzt.

[Norbert P]

In QuarkXpress konnte ich alle paar Minuten automatisch Sicherheitskopien speichern lassen, dabei blieb nur eine bestimmte Anzahl von »Versionen« bestehen. Beide Werte konnte ich festlegen. Das war doch recht praktisch. Gibt es – außer diesen »Rescue-Dateien« à la ~[Titel]~[Code].idlk – eventuell eine Funktion oder ein Script, das in InDesign Ähnliches bewirkt? Z. B.: Alle 5 Minuten als idml im Ordner X speichern und nur die letzten 5 Kopien behalten?

[Liuscorne]

Und ein Hinweis, weil ich diese Erfahrung vor kurzem gemacht habe (allerdings mit einer älteren InDesign-Version): Nachdem das Programm das erste Mal abgestürzt war, habe ich, wie empfohlen, in relativ kurzen Intervallen die Datei jeweils unter neuem Namen gespeichert, damit bei erneutem Absturz möglichst wenig verlorengeht. Nach dem nächsten Absturz habe ich also die letzte "sicher" abgespeicherte Datei geöffnet. Es kam die Abfrage, ob ich die abgestürzte Datei wiederherstellen möchte. Ich dachte: "Probieren kann ich's ja; mehr als ein nicht erfolgreicher Versuch der Wiederherstellung kann ja nicht passieren". Das stimmte leider nicht. Nicht nur war die aktuelle Datei korrumpiert; beim Versuch der Wiederherstellung hat InDesign auch die letzte Sicherheitskopie mitgeöffnet, die damit auch korrumpiert war. Ich musste also eine weitere Dateiversion zurückgehen und habe damit einen Arbeitsabschnitt verloren.

Mit anderen Worten: Augen auf bei der Wiederherstellung von Dateiversionen.

[Markoff]

Hans Haesler hatte vor längerer Zeit einmal ein Skript geschrieben, mit welchem man gezielt Sicherheitskopien mit fortlaufenden Versionsnummer in einem vorher gewählten Backup-Ordner erstellen kann. Allerdings kann ich nicht sagen, ob das Skript mit den heutigen InDesign-Versionen noch funktioniert, bei mir ist es nicht mehr im Einsatz. 

 

Natürlich löst es das aktuelle Problem der korrumpierten Datei nicht, aber vielleicht ist es für zukünftige Projekte dennoch interessant. Die Sicherung der Kopien muss zwar immer noch manuell angestoßen werden – hat man allerdings einmal einen größeren Datenverlust erlitten, ist die Nutzung des Skripts ganz schnell ins Standard-Repertoire aufgenommen. Vor allem, wenn man es auf ein Tastaturkürzel legt. 

 

Skriptsammlung des HDS-Forums: Link

Das Skript nennt sich SicherungsKopie

 

Vielleicht ist es für den ein oder anderen interessant, ich hoffe es funktioniert noch.

[Sebastian Nagel]

Dateiversionen erzeugen wäre ja eigentlich eine klassische Aufgabe für ein Betriebssystem bzw. Cloud-Dienste, nicht ein einzelnes Anwendungsprogramm, das das immer mehr schlecht als recht erledigen kann und das Problem im nächsten Programm wieder auftauchen lässt.

 

Wir hatten hier mal ein ähnliches Thema:
https://www.typografie.info/3/topic/39592-indesign-dokument-überspeichert/

 

In kurz:
– MacOS könnte sowas bei nativen Apps, aber Adobe nutzt das leider nicht
– Apples Timecapsule/Timemachine/... wäre eine Option
– Windows' Schattenkopie-Funktion macht das (wenn aktiviert) immer, ohne dass das Anwendungsprogramm was weiß oder tun muss
– Adobe sichert Dateiversionen in der Cloud, d.h. man kann zurück springen. Dafür muss man die Daten-Cloud aktiviert haben
– NAS-Speicher (Synology, QNAP, ...) mit modernen Dateisystemen (BTRFS ...) können Dateiversionen vorrätig halten ohne gleich alle Kapazitäten zu sprengen

[Phoibos]

vor 41 Minuten schrieb Sebastian Nagel:

nicht ein einzelnes Anwendungsprogramm

Da widerspreche ich vehement. Ein gut durchdachtes Programm sollte in der Lage sein, in frei definierbaren Abständen ein Save As aktuelles-arbeitsdokument[timestamp].bak zu erstellen. In den Neunzigern konnten das die üblichen Büroanwendungen, wenn ich mich recht entsinne. Sich darauf zu verlassen, dass das Betriebssystem oder das Filesystem macht, ist unglaublich fahrlässig, die sollen solchen Funktionalitäten ja nicht ersetzen, sondern eine weitere Schicht an Datenintegrität liefern.
Die Art, wie Indesign das bewerkstelligt, ist einfach grundlegend fehleranfällig, denn mit jeder Speicherung verlierst Du alle Diff-Speicherpunkte. So summieren sich dann Fehler und gekippte Bits. Da ist ein händisches Zusammenführen von arbeitsdokument[v34].bak mit arbeitsdokument[v178].bak doch einfacher.
Nur so als Beispiel, wie es bei Softmaker Office (Windows) aussieht:

[Norbert P]

vor einer Stunde schrieb Sebastian Nagel:

schlecht als recht

Quark konnte (kann) das ganz gut. Ich hatte damals einen Ordner für die Sicherheitskopien, da hatte ich sofort Zugriff, ohne Vertun. Mal ein (altes) Beispiel:

Warum InDesign so etwas nicht kann, ist mir schleierhaft.

[Sebastian Nagel]

(oje, das ist jetzt ein Exkurs geworden – ich hoffe das Thema ist damit nicht gekapert)

 

Mit "mehr schlecht als recht" meinte ich, dass, ganz egal wie gut ein Programm das vielleicht macht, es immer eine Insellösung ist – sie funktioniert nur in diesem Programm, im nächsten Programm wieder anders, und in vielen gar nicht – und ich muss es für jedes Programm konfigurieren. Die erzeugten Backup-Datensammlungen sind uneinheitlich und unvollständig, es wird Platz "verschwendet" – das ist gesamt betrachtet mehr schlecht als recht.

Die Aufgabe von Indesign ist ja auch nicht Dateimanagement, sondern Layouts erstellen (was man erwarten können sollte ist natürlich, dass sie ihr eigenes Dateiformat konsistent speichern oder das Format fehlertolerant einlesen kann). Warum nicht die Aufgabe von Dateimanagement, Datei-Historie und Sicherungen der Ebene überlassen, die dafür konzipiert und getestet ist? Sich nicht aufs Betriebssystem zu verlassen würde heißen, sich auch nicht auf Speichermanagement, Taskmanagement, I/O, Datenspeicher etc. zu verlassen. Sollte man auch nicht, aber die Absicherung vor Fehlfunktionen des gesamten Systems kann nicht Aufgabe einer Einzelanwendung sein die darauf läuft (das auszulagern und Anwendungs-übergreifend zu machen, dafür wurden Betriebssysteme ja initial erfunden). Für Absicherung ist viel mehr system-übergeordnet ein Fehlerkorrektursystem (wie ECC-RAM und RAID1/Raid5, Speicherverschlüsselung, Software-Wächter, ...) sowie ein unabhängiges Backupsystem zuständig.

Der einzige Vorteil, das auf Anwendungsebene zu machen, ist, dass man auf sehr überschaubarem Level Kopien erzeugt, d.h. die Zugänglichkeit sehr sehr einfach ist – aber das ist natürlich nur so lange ein Vorteil, solange man andere Systeme nicht im Einsatz und in der Praxis hat und der Umgang damit alltäglich ist.

 

Wir haben z.B. ein Synology-NAS im Einsatz, das sämtliche Daten die wir dort bearbeiten, versioniert. Wir können jeden einzelnen Speicherstand in der Historie wiederherstellen, oder (unser pragmatischer Ansatz zwischen Platzbedarf und Nutzen) in 15-Minuten-Schritten zurückwandern – d.h. jede defekte Datei, egal aus welchem Grund, verursacht maximal 15 Minuten Zeitverlust. Man navigiert (ganz normal im Finder, Explorer etc.) erst in den gewünschten Historien-Zeitpunkt, und hat dann die gesamte Ordnerstruktur vor sich, so als wäre man in der "Live"-Version, nur eben "von vorhin", sucht sich seine Datei, und stellt sie wieder her – das kann jeder Mitarbeiter jederzeit anwenden, und es funktioniert mit jeder Datei aus jedem Programm – gespeichert wird als Differenz, d.h. der Platzbedarf multipliziert sich hier nicht. 15-Minuten geht einen Tag zurück, dann behalten wir Tagesversionen, eine Wochenversion und eine Monatsversion. Umgesetzt wird das von Synology mittels BTRFS-Dateisystem, das all diese Funktionen implementiert – Synology macht nur den Zugriff darauf intuitiv.

Darauf muss man sich verlassen, richtig. Gegen Hardware-Ausfälle abgesichert wird das im Betrieb mit einem RAID5-Array aus Festplatten in dem 2 zugleich ausfallen dürfen ohne einen Verlust zu haben, und gegen Hardwareausfälle UND massive Softwarefehler natürlich mit klassischen Backups auf externe Laufwerke. Nötig waren diese Backup-Systeme seit 2014 bisher zum Glück noch nicht.

Kanonen auf Spatzen? Nur, wenn eine defekte Datei (nicht nur .indd) die man gerade dringend braucht, nur ein Spatz ist. Teuer? Ja, aber weniger als ein gut ausgestatteter iMac ...

[Diwarnai]

vor 5 Minuten schrieb Sebastian Nagel:

ich hoffe das Thema ist damit nicht gekapert

Nö, ist es nicht . Ich finde die Blicke über den Suppentellerrand immer wertvoll. Besonders, nachdem mein ursprüngliches Problem ja wohl weder Erklärung noch Lösung hat.

 

[Phoibos]

vor 2 Stunden schrieb Sebastian Nagel:

Warum nicht die Aufgabe von Dateimanagement, Datei-Historie und Sicherungen der Ebene überlassen, die dafür konzipiert und getestet ist?

Weil das Betriebssystem dafür nicht orignär zuständig ist. Die jeweilige Anwendung ist für seinen RAM-Speicher selbst zuständig (Browser bieten beispielsweise sogar ein eigenes Taskmanagement für ihren Arbeitsspeicher an). Das Speichern von Sicherungskopien ist kein Dateimanagement.
Das Betriebssystem stellt den Anwendungen nur Ressourcen zur Verfügung und verwaltet diese und bietet ein paar Schutzebenen, unter anderem auch für Programme, die selbst sich nicht kümmern wollen/können.
Dass Adobe die Arbeit ihrer Kunden darauf wettet, dass es schon irgendwie klappen wird, spricht nicht sehr für den Marktführer...
Und Sicherungskopien sind wirklich kein Raketentechnologie, Jeder bessere Texteditor kann das. Das ist einfach pure Nachlässigkeit.

[Microboy]

vor 13 Stunden schrieb Sebastian Nagel:

Kanonen auf Spatzen?

Der System-Admin in einer Agentur in der ich vor Jahren mal gearbeitet habe sagte immer: »Backups kosten nur wenn man keine hat.«