Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>festplatte befreien - photo library.migratedphotolibrary - wichtig?

festplatte befreien - photo library.migratedphotolibrary - wichtig?

Dr.....X22.05.2323:49
Hallo,

Mein nächster geplanter Schritt zum Thema Mac (mittlerweile Monterey , seit ca 15 Jahren immer "drüberinstalliert") SSD freischaufeln / aufräumen:

Ich habe eine alte fotos library im Ordner Bilder gesehen mit Namen ".....migratedphotolibrary" - 220 GB , änderungszeitpunkt 2017. (plausible größe / datum zum Zeitpunkt der migration von alter MacOS iphoto app auf neue Fotos app)

aktuelle library (400 GB, änderungszeitpunkt heute) steht daneben.

ich denke ich kann "migrated" löschen (nach sicherungskopie auf extern), und es gibt keine probleme - werde zum verifizieren nach löschen in Fotos.app alte Fotos checken (inklusive metadaten)

einziger grund zum zweifeln: warum hat MacOS das nicht bei erfolgreicher Migration selbst gemacht?

Mein googeln bringt keine klaren ergebnisse...

Steht noch die Aussage, (die ich mal irgendwo in Foren gelesen hatte) dass bei AFPS (oder wie apple file system heisst) die library - Größen-Angabe nicht so ernst zu nehmen ist, weil die alte library irgendwie nun als Verweis für die neue gilt (was bedeuten würde a) nicht löschen weil noch täglich genutzt und b) keine Festplattenersparnis)

was meint ihr?
0

Kommentare

Marcel Bresink23.05.2308:40
Dr.....X
Ich habe eine alte fotos library im Ordner Bilder gesehen mit Namen ".....migratedphotolibrary"

Das ist eine alte Sicht auf die Bilderdatenbank, aus der Zeit als "Fotos" noch "iPhoto" hieß. Falls nötig, könnte man die Bilder aus dieser Zeit noch mit iPhoto öffnen. Ansonsten erfüllt dieses Bundle keinen Zweck mehr.
Dr.....X
einziger grund zum zweifeln: warum hat MacOS das nicht bei erfolgreicher Migration selbst gemacht?

macOS ist daran nicht selbst beteiligt. Das ist eine Funktion von "Fotos". Wenn ein Benutzer seinen Bilderordner gleichzeitig mit iPhoto und Fotos in verschiedenen Betriebssystemen verwenden wollte, wäre es eine Katastrophe, wenn ein Programm einfach seine Daten löschen würde. Das macht man grundsätzlich nicht.

Die "Migrated Library" braucht außerdem so gut wie keinen Speicherplatz, da die ganzen Bilddaten entfernt und durch symbolische Links auf die aktuellen Dateien ersetzt worden sind.
Dr.....X
Steht noch die Aussage, dass bei AFPS die library - Größen-Angabe nicht so ernst zu nehmen ist,

APFS hat damit nichts zu tun. Es ist richtig, dass bei Verwendung von APFS die oben angesprochene Speicherplatzersparnis vollautomatisch konstruiert werden könnte (ein und dasselbe Bild in zwei Ordnern auf dem gleichen Datenträger wird nur einmal gespeichert). Hier in diesem Fall spielt das keine Rolle, da "Fotos" diesen Trick auch ohne APFS sozusagen von Hand selbst angelegt hat. Das klappt auch mit HFS+ und würde sogar über mehrere Datenträger hinweg funktionieren.

Den Speicherplatzverbrauch durch Summieren von Einzeldateien zu berechnen, funktioniert in modernen Betriebssystemen grundsätzlich nicht mehr. Kommt noch ein modernes Dateisystem (wie APFS) hinzu, erst recht nicht. Da können auch Volumes nicht mehr summiert werden, um ein korrektes Ergebnis zu erhalten.
+3
MikeMuc23.05.2308:57
Marcel Bresink
d.h. du willst damit ausdrücken, das aufgrund von Symlinks die Datei / das Bundle nicht gelöscht werden darf.
Oder ist das Dateisystem so intelligent, das man diese Datei nun löschen kann, es aber unterm Strich nur wenig mehr freien Speicherplatz bringen wird weil vieles davon aufgrund der Doppelverwendung eben nicht gelöscht wird?

Die Kernfragen waren ja:
- „kann das weg“
- wird es mehr freien Speicher bringen wenn es gelöscht wird


Dazu meine allgemeine Frage:
Wie findet man heutzutage große „Dateileichen“ wenn man sich nie sicher sein kann, das noch irgendwo Symlinks darauf anderswo genutzt werden. Grad wenn man Platz schaffen will / muß.
0
Marcel Bresink23.05.2309:23
MikeMuc
d.h. du willst damit ausdrücken, das aufgrund von Symlinks die Datei / das Bundle nicht gelöscht werden darf.

Nein, im Gegenteil. Das Bundle besteht nur aus Symlinks und alten iPhoto-Datenstrukturen. Es kann problemlos gelöscht werden, wenn Du iPhoto nicht mehr nutzt. Da Symlinks fast keinen Platz brauchen, bringt das nur nicht viel.
MikeMuc
Wie findet man heutzutage große „Dateileichen“ wenn man sich nie sicher sein kann, das noch irgendwo Symlinks darauf anderswo genutzt werden.

Die Frage ist ein Widerspruch in sich. Wenn etwas genutzt wird, ist es keine "Dateileiche".
+6
MikeMuc23.05.2311:58
Schon klar, das es dann keine echte Leiche ist. Nur wie erkennt man das wenn man "die gleiche Datei" von 2 verschiedenen Ordnern aus "anschaut". Beim ersten könnte man. aus dem Kontext schließen, das man löschen darf, bei 2. Ablageordner wäre einem sofort klar, das man die noch braucht. Der unbedarfte User "sieht, das die Dateigröße am ersten Ort groß ist, löscht die Datei und stellt dann fest wundert sich, das es trotzdem nicht mehr freien Speicher gibt weil "das Original wegen einem Symlink von woanders eben nicht gelöscht wird. Dieser Zusammenhang hat leider keine "transparente Außendarstellung gegenüber dem normalen User".
Dieses Links sorgen zwar für eine möglichst optimale Speicherausnutztung der teueren (meist zu kleinen) Apple-SSDs aber das Usererlebnis leidet halt darunter. Deswegen haben wir ja auch immer wieder hier im Forum das Thema, das die Speicherplatzangaben von Apple an diversen Orten unterschiedlich sind. Wenn man früher 2 GB gelöscht hat, dann waren schließen 2GB Speicher mehr frei. Heute kann es sein, das die noch lange nicht zur neuen Benutzung zur Verfügung stehen weil die in Wirklichkeit garnicht gelöscht wurden Apple stand mal für "einfach", aber das war einmal.
0
Marcel Bresink23.05.2312:10
Diese Argumentation ergibt nicht viel Sinn. Die Technik hat sich in den letzten 30 Jahren halt weiterentwickelt. Die Vorstellung, dass Speicher frei wird, wenn man eine Datei löscht, stimmt halt nicht mehr. Die "einfache" Apple-Vorgehensweise ist, sich nicht darum zu kümmern. Dass das problematisch sein kann, liegt ja in Wirklichkeit eher daran, dass Apple zu wenig Speicher zu überhöhten Preisen verkauft.

Und in diesem ganz speziellen Fall liegt es nicht an moderner Speichertechnik. Dass das intern nur Links sind, die vom Finder als Aliase dargestellt werden, sieht man nach Öffnen der MigratedPhotoLibrary. Aliase gibt es bei Apple seit 1991.
+6
MikeMuc23.05.2312:33
Otto Normaluser will da aber nicht rein schauen. Der sieht nur die Größenangabe im Finder. Die Größen der Originale (also da wohin die Aliase zeigen), wurden zumindest früher nicht zur Berechnung der Größe eines übergeordneten Ordners herangezogen. Wenn heute ein Bundle mit lauter Symlinks drin aber 300GB hat, dann müßen s schon verdaut viele Aliase / Symlinks / was auch immer sein um auf solche Zahlen zu kommen. Oder es wird heute eben anders gerechnet. Ist das einleuchtend für Otto Normaluser? Ich würde sagen: nein
+1
konnektor23.05.2313:37
MikeMuc
Otto Normaluser will da aber nicht rein schauen. Der sieht nur die Größenangabe im Finder. Die Größen der Originale (also da wohin die Aliase zeigen), wurden zumindest früher nicht zur Berechnung der Größe eines übergeordneten Ordners herangezogen. Wenn heute ein Bundle mit lauter Symlinks drin aber 300GB hat, dann müßen s schon verdaut viele Aliase / Symlinks / was auch immer sein um auf solche Zahlen zu kommen. Oder es wird heute eben anders gerechnet. Ist das einleuchtend für Otto Normaluser? Ich würde sagen: nein
Naja, war es jemals für den Dau einfach zu entscheiden, ob er Dateien löschen darf, die er nicht selbst erstellt hat? Logs und Caches können wirklich den Platz zumüllen und löschen derselben tatsächlich Platz freigeben aber man musste schon immer wissen, was man da tut und welche Auswirkungen es hat. Ich sehe jetzt keinen großen Unterschied zu heute.
+1
Dr.....X23.05.2322:21
so, ich habe es (...migratedlib (214 GB) gelöscht:

infos laut "Apfel - Über diesen Mac - Festplatten - verwalten"

vorher
- [ ] frei 958
- [ ] fotos 446.5
- [ ] dokumente 263 (inkl migratedlib)
- [ ] beim klick auf löschen gibts ne systemwarnung: „…wird gelöscht und 214 GB werden dauerhaft frei“

nachher
- [ ] frei 1TB
- [ ] fotos 446.5
- [ ] dokumente 49

Also irgendwie sind scheinbar 42 GB frei geworden - nicht die 263 der migratedlib, auch auch zuviel um nur Aliase zu sein.

In der Fotos app sieht alles normal aus, auch bei den ganz alten fotos...

Wer eine Erklärung für die Zahlen hat, bitte posten.

Alles nicht so user-friendly - auch wenn "heutzutage Dateigrößen und freier Speicherplatz nicht mehr so einfach zu erklären sind" ist das - also die Umsetzung der Darstellung / Auflistung / Quantifizierung im OS nicht so richtig Enduser-tauglich , meiner Meinung nach. Es ist ja extra ein Dialog, um dem User zu helfen, Speicherplatz frei zu räumen / zu optimieren. Meiner Meinung nach hohe Frustgefahr, damit nicht optimal.
0
konnektor24.05.2307:56
Dr.....X
Wer eine Erklärung für die Zahlen hat, bitte posten.
Das steht doch schon oben:
... und alten iPhoto-Datenstrukturen.
Von nur Aliase war keine Rede.
Alles nicht so user-friendly - auch wenn "heutzutage Dateigrößen und freier Speicherplatz nicht mehr so einfach zu erklären sind" ist das - also die Umsetzung der Darstellung / Auflistung / Quantifizierung im OS nicht so richtig Enduser-tauglich , meiner Meinung nach. Es ist ja extra ein Dialog, um dem User zu helfen, Speicherplatz frei zu räumen / zu optimieren. Meiner Meinung nach hohe Frustgefahr, damit nicht optimal.
Nochmal, wo ist der Unterschied? Ob Du das löschen kannst hättest Du so oder so nicht gewusst, egal ob die nach Deines Ansicht korrekte Größe angezeigt wird. Also ...

Frage: 42GB, kann man das löschen?
Antwort: ja, wenn Du iPhoto nicht verwendest.

Frage: 214GB, kann man das löschen?
Antwort: ja, wenn Du iPhoto nicht verwendest. Es wird aber nicht so viel frei werden.

Wo ist das erste jetzt more user-friendly?
0
MikeMuc24.05.2308:00
Sehr interessant diese Zahlen. Bei den Dokumenten sind es genau die 214 weniger… effektiv hat die Aktion aber nur 50GB gebracht.
Das zeigt ja anschaulich, wie intransparent oder verkorkst die Anzeige / Berechnung von Apple ist.
Ich bin ebenfalls auf eine plausible Erklärung für Otto Normaluser gespannt.
0
Marcel_75@work
Marcel_75@work24.05.2308:01
Um "Platzfresser" aufspüren zu können, kannst Du z.B. das Freeware-Tool "OmniDiskSweeper" nutzen.



Funktioniert schneller und meiner Erfahrung nach auch zuverlässiger als die Apple Bordmittel per GUI.

PS: Statt direkt per "OmniDiskSweeper" zu löschen am besten immer erst noch mal an die entsprechende Stelle im Finder springen. Und dort dann in Ruhe entscheiden, ob das weg kann…
+2
MrChad24.05.2308:51
MikeMuc
Ich bin ebenfalls auf eine plausible Erklärung für Otto Normaluser gespannt.
Einer -von mehreren- Gründen für inkonsistente Speicherplatzangaben ist die Eigenschaft von APFS, Dateien zu clonen, d.h. beim kopieren einer Datei wird nicht wirklich neuer Plattenplatz benötigt. Dieser wird erst dann (teilweise) angelegt, wenn eine der beiden Kopie verändert wird.

Auf dem Bild kann man z.B. sehen, dass ich ohne Probleme 5 Kopien einer 10 GB Datei (= 60 GB) auf einem kleinen Volume anlegen kann, das insgesamt nur 60 GB groß ist.

Das GUI sagt mir jetzt, dass jetzt über 80 GB auf dem 60 GB Volume liegen.
Terminal sagt mir gleichzeitig, dass insgesamt nur 15 GB benutzt sind.
+2
Marcel Bresink24.05.2309:28
Dr.....X
infos laut "Apfel - Über diesen Mac - Festplatten - verwalten"

Diese Anzeige wurde ursprünglich für iPhones entwickelt und ist für den Mac komplett unbrauchbar. Es gibt nur wenige macOS-Versionen, wo die angezeigten Werte einigermaßen plausibel und nicht komplett falsch sind. Da, wo es einigermaßen funktioniert, werden zum größten Teil Schätzungen von Spotlight angegeben. Außer bei der Anzeige von Einzeldateien sind die Werte irreführend. Und was Apple nun genau z.B. als "Systemdatei" ansieht, weiß auch niemand.

Die exakten und korrekten Zahlen über den tatsächlichen Speicherverbrauch sind im Festplattendienstprogramm zu finden.
+3

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.