macOS Mojave Unnötige Sicherung unter Time Machine???

Das Problem sind nicht Metadaten an sich, sondern nur ein einziges ganz bestimmtes erweitertes Attribut, das Apple eingeführt hat: com.apple.lastdateused. Und das hat nur dem Zweck zu speichern, wann die Datei zuletzt angefasst, also z.B. gelesen wurde.

Unter den altbekannten Unix-Attribute gibt es schon lange eines für genau das gleiche: die access time. Die wird aber nicht in der Datei vermerkt, sondern im Verzeichniseintrag. Und jetzt kommts. Eine Änderung dieses Attributes löst mit Timemachine keine Sicherung der Datei aus.
Nur weil Apple aber dieses erweiterte Attribut erfunden hat (wohl um die Auslagerung in die iCloud zu ermöglichen) und das Ganze eben als Dateibestandteil angesehen wird, erfolgt eine erneute Sicherung, obwohl die identische Informationen an anderer Stelle schon vorhanden ist und dort nichts triggert.

Übrigens, auch arq zeigt exakt das gleiche Verhalten. Offensichtlich wird auch hier das als Änderung der Datei angesehen.

@Olivetti wenn das bekannte Programm mit den 3 gleichen Buchstaben auch die systemseitigen Funktionen nutzt und nicht rsync pur, dann wird das dort wohl auch so sein.
 
  • Gefällt mir
Reaktionen: tocotronaut, iPille und bowman
iPille schrieb:
Definiere Datenbestand!

Daten sind alles oder nur die "echten" Daten? Zählen Metadaten zu "echten" Daten oder zum Wasserkopf?
Zum Vergrößern anklicken....
Datenbestand ist die Datei. Wenn die sich ändert, weil Metadaten geändert wurden, habe ich zwei Version dieser Datei. Welche soll gesichert werden?
Anderes Beispiel: *.m4a iTunes-Titel
Du änderst das Cover, die Musik bleibt gleich? Du hast zwei Versionen der Datei. Welche möchtest du wiederherstellen? Ich möchte die neue Version ab jetzt gesichert haben. Das ist mein Verständnis von Time Machine. Sicherung des aktuellen Datenbestandes, um ihn jederzeit mit Stand von jetzt wiederherstellen zu können.

Ansonsten hilft dir nur ausschließen vom Backup und einen alternativen Weg zur Sicherung suchen. Es gab ja schon Vorschläge.
 
  • Gefällt mir
Reaktionen: iPille
Gwadro schrieb:
Datenbestand ist die Datei. Wenn die sich ändert, weil Metadaten geändert wurden, habe ich zwei Version dieser Datei. Welche soll gesichert werden?
Anderes Beispiel: *.m4a iTunes-Titel
Du änderst das Cover, die Musik bleibt gleich? Du hast zwei Versionen der Datei. Welche möchtest du wiederherstellen? Ich möchte die neue Version ab jetzt gesichert haben. Das ist mein Verständnis von Time Machine. Sicherung des aktuellen Datenbestandes, um ihn jederzeit mit Stand von jetzt wiederherstellen zu können.

Ansonsten hilft dir nur ausschließen vom Backup und einen alternativen Weg zur Sicherung suchen. Es gab ja schon Vorschläge.
Zum Vergrößern anklicken....

Tja, so ist das ja auch richtig, aber ich wüsste nicht mal soooo ganz genau, wo iTunes das Cover speichert:

• in der Musikdatei
• in irgendeiner iTunes-Library
• sonstwo

Wo wird eigtl. meine Bewertung des Titels gespeichert? Und gibt es einen Unterschied zwischen *.m4a und *.mp3? Wird die *.mp3-Datei denn auch verändert, wenn ich deren Bewertung ändere???
 
Zuletzt bearbeitet:
lisanet schrieb:
Das Problem sind nicht Metadaten an sich, sondern nur ein einziges ganz bestimmtes erweitertes Attribut, das Apple eingeführt hat: com.apple.lastdateused. Und das hat nur dem Zweck zu speichern, wann die Datei zuletzt angefasst, also z.B. gelesen wurde.

Unter den altbekannten Unix-Attribute gibt es schon lange eines für genau das gleiche: die access time. Die wird aber nicht in der Datei vermerkt, sondern im Verzeichniseintrag. Und jetzt kommts. Eine Änderung dieses Attributes löst mit Timemachine keine Sicherung der Datei aus.
Nur weil Apple aber dieses erweiterte Attribut erfunden hat (wohl um die Auslagerung in die iCloud zu ermöglichen) und das Ganze eben als Dateibestandteil angesehen wird, erfolgt eine erneute Sicherung, obwohl die identische Informationen an anderer Stelle schon vorhanden ist und dort nichts triggert.
Zum Vergrößern anklicken....


Gelegentlich geht APPLE, wie schon mit seiner Hardware, sehr eigene Wege. Und das, obwohl es andere, gelegentlich einfachere Lösungen schon gibt. Wenn dabei eine deutliche Verbesserung für mich als Kunde herauskommt, dann von mir aus. Wenn es aber vordergründig dem Vorteil von APPLE dient, vergeht mir das Vergnügen. Selbst wenn mir APPLE damit das Leben unnötig schwerer macht als vorher, finde ich das einfach nervig.

Just bei diesem Problem hier schein es sich so zu verhalten. Ich nutze die iCloud nur sehr selten und kann daher für mich keine Verbesserung, aber eine deutliche Verschlechterung feststellen - ergo ich finde es nicht gut.
 
  • Gefällt mir
Reaktionen: dg2rbf
Ist com.apple.lastdateused identisch zu kMDItemLastUsedDate oder sind das zwei unterschiedliche Attribute?
 
Zuletzt bearbeitet:
@lisanet
bestimmt auf APFS, aber auch auf HFS+?

@mj
vermutlich nicht, also letzteres, weil das kMDZeugs doch traditionell zur spotlight-extrawurst gehört.
je mehr man da nachguckt, desto wirrer wird es. kein wunder, dass sie ihre logs nicht mehr in den griff bekommen haben. :crack:

---

kann jemand mit solch attributierter datei bitte mal mit angabe, ob APFS oder HFS+
Code: 
ls -lO@ datei
stat datei
mdls datei
ausgeben.
 
iPille schrieb:
Tja, so ist das ja auch richtig, aber ich wüsste nicht mal soooo ganz genau, wo iTunes das Cover speichert:

• in der Musikdatei
• in irgendeiner iTunes-Library
• sonstwo

Wo wird eigtl. meine Bewertung des Titels gespeichert? Und gibt es einen Unterschied zwischen *.m4a und *.mp3? Wird die *.mp3-Datei denn auch verändert, wenn ich deren Bewertung ändere???
Zum Vergrößern anklicken....

es kommt drauf an...

aus dem store Geladene cover werden in der mediathek gesichert.
Manuell eingebundene cover werden in der datei gesichert.

Bewertungen sind in der mediathek.
Genauso der playcount und der zuletzt gespielt zeitstempel.
 
  • Gefällt mir
Reaktionen: dg2rbf, iPille und Gwadro
tocotronaut schrieb:
es kommt drauf an...

aus dem store Geladene cover werden in der mediathek gesichert.
Manuell eingebundene cover werden in der datei gesichert.

Bewertungen sind in der mediathek.
Genauso der playcount und der zuletzt gespielt zeitstempel.
Zum Vergrößern anklicken....

Tja, hier enden meine Möglichkeiten. Trotzdem kommen mir manche Entscheidungen dort nicht clever vor. Aber, ich bin eben kein Fachmann...
 
mj schrieb:
Ist com.apple.lastdateused identisch zu kMDItemLastUsedDate oder sind das zwei unterschiedliche Attribute?
Zum Vergrößern anklicken....
Olivetti schrieb:
@mj
vermutlich nicht, also letzteres, weil das kMDZeugs doch traditionell zur spotlight-extrawurst gehört.
je mehr man da nachguckt, desto wirrer wird es. kein wunder, dass sie ihre logs nicht mehr in den griff bekommen haben. :crack:
Zum Vergrößern anklicken....

ich muss das korrigieren (aufgrund des anderen aktuellen threads), weil mir das nicht aufgefallen ist und hier wohl auch sonst niemandem.
das attribut heisst natürlich "com.apple.lastuseddate", nicht "…lastdateused" und so wird es dann auch dasselbe attribut in spotlight sein.

kann jemand mit solch attributierter datei bitte mal mit angabe, ob APFS oder HFS+
Code: 
ls -lO@ datei
stat datei
mdls datei
ausgeben.
Zum Vergrößern anklicken....
ist leider wie in der politik, wenn keiner mitmacht, fällt auch lange nix auf. :noplan:
 
  • Gefällt mir
Reaktionen: iPille, mausfang, dg2rbf und eine weitere Person
Code: 
ls -lO@ test.txt
-rw-r--r--@ 1 simone  staff  - 4  8 Feb 13:42 test.txt
    com.apple.lastuseddate#PS    16
Code: 
stat test.txt
16777220 19958786 -rw-r--r-- 1 simone staff 0 4 "Feb  8 13:48:11 2020" "Feb  8 13:42:08 2020" "Feb  8 13:48:11 2020" "Feb  8 13:34:54 2020" 4096 8 0x40 test.txt
Code: 
mdls test.txt
_kMDItemDisplayNameWithExtensions      = "test.txt"
kMDItemContentCreationDate             = 2020-02-08 12:34:54 +0000
kMDItemContentCreationDate_Ranking     = 2020-02-08 00:00:00 +0000
kMDItemContentModificationDate         = 2020-02-08 12:42:08 +0000
kMDItemContentModificationDate_Ranking = 2020-02-08 00:00:00 +0000
kMDItemContentType                     = "public.plain-text"
kMDItemContentTypeTree                 = (
    "public.plain-text",
    "public.text",
    "public.data",
    "public.item",
    "public.content"
)
kMDItemDateAdded                       = 2020-02-08 12:34:54 +0000
kMDItemDateAdded_Ranking               = 2020-02-08 00:00:00 +0000
kMDItemDisplayName                     = "test.txt"
kMDItemDocumentIdentifier              = 3408
kMDItemFSContentChangeDate             = 2020-02-08 12:42:08 +0000
kMDItemFSCreationDate                  = 2020-02-08 12:34:54 +0000
kMDItemFSCreatorCode                   = ""
kMDItemFSFinderFlags                   = 0
kMDItemFSHasCustomIcon                 = (null)
kMDItemFSInvisible                     = 0
kMDItemFSIsExtensionHidden             = 0
kMDItemFSIsStationery                  = (null)
kMDItemFSLabel                         = 0
kMDItemFSName                          = "test.txt"
kMDItemFSNodeCount                     = (null)
kMDItemFSOwnerGroupID                  = 20
kMDItemFSOwnerUserID                   = 501
kMDItemFSSize                          = 4
kMDItemFSTypeCode                      = ""
kMDItemInterestingDate_Ranking         = 2020-02-08 00:00:00 +0000
kMDItemKind                            = "Reines Textdokument"
kMDItemLastUsedDate                    = 2020-02-08 12:48:11 +0000
kMDItemLastUsedDate_Ranking            = 2020-02-08 00:00:00 +0000
kMDItemLogicalSize                     = 4
kMDItemPhysicalSize                    = 4096
kMDItemUseCount                        = 19
kMDItemUsedDates                       = (
    "2020-02-07 23:00:00 +0000"
)
 
  • Gefällt mir
Reaktionen: Olivetti
Das Ganze existiert unter Catalina immer noch. Allerdings habe ich es nicht mehr bemerkt, da ich von Xcode auf VS Code umgestiegen bin.

Es scheint so, als ob es darauf ankommt, mit welchem Programm und wie man eine Datei zum _Lesen_ öffnet.

Xcode setzt / erneuert das Attribut immer, egal ob man es über Xcode -> File -> Open oder über den Finder mit Rechtsklick -> öffnen mit oder via drag&drop vom Finder auf das Xcode-Icon öffnet.

VSCode ist da anders. In VS Code -> File -> Open wird das Attribut _nicht_ gesetzt / erneuert. Verwendet man den Finder, dann schon. Ebenso ist es mit z.B BBedit.

Im Terminal mit nano (hier nano 4.2) nur lesen, wird das Attribut _nicht_ gesetzt. Auch ein touch im Terminal setzt es nicht.

Alles nicht sonderlich zufriedenstellend.
 
  • Gefällt mir
Reaktionen: iPille und dg2rbf
Hi,
ohmei ohmei, die Programmierer bei Apple haben den Groschen noch nicht fallen gehört :).

Franz
 
  • Gefällt mir
Reaktionen: iPille und efx
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten