Hallo zusammen,
aus verschiedensten Gründen habe ich derzeit in einer meiner Datenbanken eine recht große Menge an Dokumenten. U.a. wohl rund 137.000 PDF-Dateien.
Viele dieser Dateien sind Duplikate, die ich eigentlich gerne los werden würde. In der Systemseitigen Gruppe “Duplikate” wird aber leider quasi die gesamten Datenbank (167.705 Dateien) angezeigt.
Eine Kontrolle hat hier ergeben, dass DT3 wohl nicht nur die Dupletten hier anzeigt, sondern auch das “Original” einer Datei. Damit kann ich in dieser Intelligenten Gruppe nicht einfach alles löschen, da damit ja dann auch die Originale gelöscht würden.
Dazu kommt, dass DT3 wohl auch nicht vorhandene Dateien in den Duplikaten einschließt. Leider habe ich auch hier das Problem, dass ich noch keine Möglichkeit gefunden habe, diese Dateien gezielt angezeigt zu bekommen, oder z.B. eine Gruppe nach diesem Kriterium zu sortieren, um diese Dateileichen vorab zu löschen.
Wie kann ich die Datenbank am schlausten bearbeiten, damit ich meine Duplikate sicher löschen kann, und gleichzeitig am Ende keine verwaisten Dateien übrig behalte?
Weitere Frage, gibt es eine Möglichkeit Duplikate auch Datenbank übergreifend zu suchen?
Ich habe derzeit verschiedene Datenbanken, mit leider unterschiedlichen Datenbeständen, und ich würde im Ergebnis gerne als eine Art Ausgangspunkt für die weitere Arbeit mit den Datenbanken, eine (oder mehrere) Datenbanken übrig behalten, in denen jedes Dokument genau einmal irgendwo vorhanden ist?
Also insgesamt ohne Duplikate und verwaiste Dateien.
Sie könnten alle Resultate der intelligenten Gruppe auswählen und das Skript Scripts > Daten > Duplikate in Papierkorb verschieben verwenden. Dieses stellt sicher, dass jeweils ein Exemplar übrig bleibt. Allerdings wäre zumindest beim ersten Versuch eine Aktivierung der strikteren Duplikat-Erkennung (s. Einstellungen > Allgemein) sinnvoll.
Meldet denn Ablage > Datenbank überprüfen & reparieren… irgendwelche Probleme? Fehlende Dateien sollten unter Fenster > Protokoll aufgeführt werden und lassen sich dann z.B. per Kontextmenü in den Papierkorb verschieben.
Jeder Datenbankindex ist unabhängig von anderen Datenbanken und somit auch die Duplikaterkennung, d.h. das ist nicht möglich.
Danke für die Antwort.
Ich habe mich jetzt mal daran versucht, die Duplikate, wie beschrieben, über das Skript zu verarbeiten.
Leider tut das Skript gar nichts, der Papierkorb bleibt leer, und die Anzahl der Objekte in der Gruppe bleibt völlig unverändert bei 167000.
Nachdem Aufruf läuft zwar der Beachball eine ganze Zeit lang (min. 30 Min) aber wie gesagt, ohne jegliches Resultate.
Allerdings sind danach sämtliche Skripte ausgegraut, und DT3 muss neu gestartet werden, um dies zu ändern.
Ich habe das System möglicherweise überlastet.
Wenn ich nur ein paar Dateien markieren, dann landen tatsächlich welche im Papierkorb.
Problem hier, je nachdem welche Daten das sind, verschiebt mir das Skript alle Dateien in den Papierkorb.
Bei einem richtig benannten PDF hat es funktioniert, bei einem “Reinen Textdokument” (einer alten Mail), mit fünf angezeigten Dateien (4 mit der selben Dateigröße 18,6KB, eine mit 17,7KB) und einem offenbar beschädigten Namen (_0JDOC~T) werden alle 5 Versionen aus dem Ordner Duplikate in den Papierkorb verschoben.
Bei der großen Menge an Daten, die ich hier leider habe, ist das natürlich dann nicht manuell zu prüfen, ob jetzt alle Versionen einer Datei im Papierkorb landen, oder eine übrig bleibt.
Kann man das Skript im Übrigen (für mich als relativem Laien) so bearbeiten, dass beim Aussortieren die Dateien in bestimmten Ordnern als “Master” betrachtet werden?
Wenn ich nicht Datenbankübergreifend suchen kann, dann muss ich die Datenbanken zumindest vorübergehend vereinen. Dabei habe ich aber in einer Datenbank schon einige Tausend Dokumente richtig sortiert, getagt etc. Ich würde zwar gerne die Duplikate aus dem System heraus bekommen, hätte aber natürlich gerne die Daten dann aus dieser Datenbank möglichst unberührt.
Ach ja, die Reparaturfunktion meldet die Datenbank mit “9 Inkonsistenzen, 0 ungültiger Dateinamen, 103850 fehlende und 0 verwaiste Dateien.”.
Die Reparatur ergibt “103859 Fehler übrig”.
Ein zweiter Durchlauf, nachdem ich aus den Ordnern “verwaiste Dateien” rund 55.000 Dateien gelöscht hatte, ergab “9 Inkonsistenzen, 0 ungültige Dateinamen, 53329 fehlende und 0 verwaiste Dateien.”
Die fehlenden Dateien werden wie gesagt im Protokoll-Fenster aufgeführt. Sie könnten dort alle auswählen, per Kontextmenü in den Papierkorb legen und den Papierkorb leeren. Danach sollte zumindest dieses Problem behoben sein (und vermutlich auch bereits die Anzahl an Duplikaten geringer).
Das Skript überprüft explizit vor dem Verschieben eines Dokumentes in den Papierkorb, dass es nicht das letzte Duplikat (und sozusagen das “Original”) ist. Hatten Sie denn die striktere Duplikat-Erkennung aktiviert wie vorgeschlagen vor der Benutzung des Skriptes? Eventuell gab es aufgrund der standardmäßigen Einstellung unerwartete weitere Duplikate.
Ja, die striktere Erkennung ist bei mir sozusagen standardmäßig aktiviert.
Viele der Duplikate die ich in der Datenbank habe, sind tatsächlich echte Kopien der Files, d.h. die Dateien sind tatsächlich vollständig identisch, wohl auch hinsichtlich der verschiedenen Daten. Kann es daran liegen, dass das Skript keine Datei als “Original” erkennen kann?
Ein Original im wahrsten Sinne des Wortes gibt es in DEVONthink nicht (auch nicht bei Replikaten), aber das Skript erkennt, ob es bereits die letzte Instanz ist oder nicht.
Dann funktioniert das aus irgend einem Grund bei den Dateien wohl nicht.
Von 5 Dateien im Ordner Duplikate, werden alle 5 in den Papierkorb verschoben.
Ich habe jetzt aus einer Datenbank, die wohl überwiegend Duplikate zu meiner neuen Hauptdatenbank enthält, eine Reihe von Dateien in eine eigene Gruppe in meiner Hauptdatenbank dupliziert, um dort die Duplikate in dieser neuen Gruppe über die DT3 eigene Intelligente Gruppe Duplikate zu finden, und dann, durch Filtern nach dem Ort zu löschen.
Etwa die Hälfte der Dateien konnte ich so auch herausfiltern, leider habe ich nun aber in der neuen Gruppe immer noch über 180 vorwiegend PDF+Text Dateien, die von der Intelligenten Gruppe nicht als Duplikat erkannt werden, aber nach einer Stichprobenüberprüfung noch zumindest zum Großteil Duplikate schon vorhandener Dateien in der Datenbank sind.
Was mache ich falsch?
Ist es möglich, dass es Duplikate gibt, die nicht von der intelligenten Gruppe gefunden werden? Wie sehen denn die Bedingungen der intelligenten Gruppe aus?
Das ist insgesamt sogar sehr wahrscheinlich, da ich ja doppelte (identische) Dateien in der Datenbank habe, die in der Gruppe nicht auftauchen.
Hinsichtlich des Problems, dass alle Kopien gelöscht werden, trifft dies aber wohl nicht zu, jedenfalls finde ich ausser denen in der intelligenten Gruppe ersichtlichen keine weiteren Kopien. Dies würde vermutlich auch dem Funktionsprinzip des Skriptes widersprechen, da es ja, soweit ich das verstanden habe, bei seiner Arbeit nur die markierten Dateien berücksichtigt, und die liegen in dem Fall ja alle in der intelligenten Gruppe, oder verstehe ich das falsch?
Die intelligente Gruppe ist die von DT3 dort vorgegebene.
Geändert habe ich hier, zumindest bewusst, nichts.
Kann es sein, dass der Suchindex der Datenbanken beschädigt ist?
Wenn ja, wie könnte man diesen neu aufbauen?
Ich habe gerade einmal in einem von mehreren Ordnern gezählt, und komme hier auf min. 60 Duplikate von identischen Dateien.
Die Datenbankeigenschaft zeigt mir 34 replizierte Dateien für die ganze Datenbank an?
Die Statistik zeigt tatsächlich keine Duplikate, sondern Replikanten an. Erstere sind (mehr oder weniger ähnliche) Kopien, letztere zusätzliche Instanzen in der Datenbank-Struktur.
Ich habe das jetzt einmal mit einer neuen Datenbank getestet, eine Datei importiert und dupliziert. Die intelligente Gruppe “Duplikate” zeigt zunächst beide Dateien an. Wenn nun beide ausgewählt werden und das Skript Duplikate in den Papierkorb verschieben verwendet wird, befindet sich anschließend eine Kopie im Papierkorb, die zweite weiterhin in der Datenbank und die intelligente Gruppe zeigt nichts mehr an. Alles soweit wie erwartet.
Die Statistik zeigt tatsächlich keine Duplikate, sondern Replikanten an. Erstere sind (mehr oder weniger ähnliche) Kopien, letztere zusätzliche Instanzen in der Datenbank-Struktur.
Das Problem auch hier, mit Replikanten habe ich, zumindest bewusst, noch nicht innerhalb DT gearbeitet. Ich finde die Funktion recht unübersichtlich, da ich bisher nicht feststellen konnte, woran ich das Replikat vom Original unterscheiden kann.
Darüber hinaus zeigte mir die Datenbank in obigem Screenshot an, das ich 34 Relikte hätte.
Nun habe ich das Skript “Gruppe mit Replikanten” auf die Gruppe “Alle PDF-Dokumente” in der Datenbank angewandt, und erhalte eine Gruppe mit 68 Objekten, statt der zu erwartenden 34!
Nach dieser Aktion sieht die Datenbank-Struktur plötzlich so aus:
Ich würde behaupten, dass ist nicht das, was zu erwarten wäre, oder?
Was das löschen von allen Duplikaten über das Skript angeht, würde ich gerne einmal ein kleines Video übersenden. Ich nehme an, das kann ich aber nicht hier hochladen, oder?
Wohin soll ich das schicken?
OK, dann habe ich die Funktion dieses Skriptes wohl falsch verstanden. Ich habe gerade in der Hilfe eine Seite gefunden, auf der die einzelnen Skripte kurz vorgestellt werden. Das wäre sicherlich auch für andere Hilfreich, ich hätte mir hier im Skriptmenü einen Link auf diese Hilfedatei gewünscht.
Das gleiche gilt dann wohl auch für ein Replikat!?
Ich war bisher davon ausgegangen, dass ein Replikat quasi “nur” einen Verweis auf die Originaldatei darstellt, und Änderungen die ich am Replikat vornehme, daher auch auf das Original angewandt werden. Um Speicherplatz zu sparen, wird aber beim Replikat, im Gegensatz zum Duplikat, keine eigene neue Datei angelegt, mit dem Nachteil, wenn ich das Original lösche, verliert das Replikat seine Datei/Verknüpfung.
Dann stimmt das also so nicht?
Das Video sende ich erstmal nicht, ich habe gerade festgestellt, dass mir bei der Datei an der ich mich versucht habe, 13 Duplikate angezeigt werden, und die Datei auch unter einem anderen Dateinamen vorhanden ist.
Beim Auswählen aller 14 Dateien wurde tatsächlich auch nur 13 Dateien in den Papierkorb verschoben. Ich teste das in den nächsten Tagen nochmal mit anderen Dateien, aber gerade scheint es soweit geklappt zu haben.
Dabei ist mir allerdings aufgefallen, dass die nicht in den Papierkorb verschobene Version eine mit dem Zusatz “-1-4” ist (der wohl von irgendeinem Program (DT oder Finder) hinzugefügt wurde, als die Datei mal in dem selben Ordner, oder der selben Gruppe gelegen hat), es hätte aber auch eine Version ohne Zusatz im Namen bestanden, das ursprüngliche “Original” sozusagen.
Kann man das irgendwie beeinflussen, dass als “Original” die Datei übrig bleibt, bei der dieser zusätzliche Zähler fehlt?
Nein, es gibt kein Original. Die Datei wird erst gelöscht, wenn die letzte Instanz (Replikant) gelöscht wird.
Entweder müssten Sie dafür das Skript anpassen, was AppleScript-Kenntnisse voraussetzt. Oder Sie passen die Bedingungen der intelligenten Gruppe “Duplikate” an, so dass nur Elemente gefunden werden, deren Name mit 1, 2, 3 oder 4 endet.
