Deine Postings sind für mich fast immer ein Quell der Freude. (Wenn du schon immer Nr. 5 kennenlernen wolltest - du hast ihn gefunden. "Input!"
)
ich versuche jetzt mal nicht auf alle Fragen einzugehen
Viel Text, Erklärung, aber es waren diesmal nur zwei Fragen:
- Was bedeutet die Fehlermeldung "NSPOSIXErrorDomain 12", die mir SyncTime entgegenschleudert?
- Kann ich App-Container, die irrtümlich noch in meinen Installations-Quellen lagern, problemlos löschen, wenn sie bereits in den Programme-Ordner kopiert wurden (und nur von dort gestartet werden)?
Die zweite Frage kann ich nach deinem Posting wohl mit "Ja" beantworten.
Programme sind unter macOS immer ein Ordner mit der Endung .app und eine enthaltenen, fest vorgegebenen Verzeichnisstruktur.
Weder etwas dazugelernt. Dass es möglich ist, hatte ich schon gehört, dass die Vorgehensweise Standard ist, noch nicht.
Das warum können wir mal in einem separatem Thread erörtern.
Kann ich mir in etwa vorstellen, macht für mich auch Sinn.
ABER es hat sich eingebürgert, alle Programme in den Programme-Ordner zu kopieren.
Das sind sie bei mir auch und werden auch immer von dort gestartet. die für die Apps wichtigen Dateien sollten also immer richtig landen.
Unter macOS gibt es ein paar recht sinnvolleEigenschaften eines Dateisystems, die unter NTFS si nciht funktionieren können.
Ja, und vice versa.
Solltest du zwingend darauf angewiesen sein, dass du einen Datenträger (Stick oder Platte) auch an einem Windows-Rechner verwenden musst und das nicht anders lösen kannst (via Netzwerkfreigaben) verwende für diesen Datenträger ExFAT.
Das hat sich so einfach nicht als praktikabel erwiesen, wiewohl ich schon extern mit exFAT formatiert hatte. Netzwerk gibt es bei mir natürlich, aber keine Netzwerkrechner oder NAS. Zugang zum Web ... das war's. Kein Platz mehr wie früher. Und eigentlich auch kein Interesse, mir reicht ein Monster zu Hause bereits.
Extern muss ich, wenn, dann "aushäusig" arbeiten. Und dann meist unter Windows. exFAT hat sich dabei nicht als ausreichend hilfreich erwiesen. Ich muss mit zwei externen Laufwerken nämlich laufend arbeiten. Das ginge sich intern - jetzt mal ganz abgesehen von den nahezu unverschämten Kosten für Apple-SSD-Erweiterungen bis max. 8TB nicht aus. Und DAS Programm, mit dem ich außer Haus arbeiten muss, ist bei der Absturzhäufigkeit unter Windows unter exFAT ein echter Risiko-Kandidat. Prooved.
Für Ziele von Backups verwende immer APFS
Das lässt sich zumindest großteils langsam umstellen. Langsam wegen der enormen Datenmengen. Das dauert.
Deine Dateinamen beinalten das Zeichen &.
Oups! Eher nicht beabsichtigt, habe ich aber auch eben gesehen. Echt dämlich! Kann aber nicht Auslöser dieses Fehlers in SyncTime sein, weil derselbe Fehler in anderen Stellen auch auftritt, die keine Sonderzeichen beeinhalten. Den einen Fehler aber kann ich gleich mal korrigieren.
Sonderzeichen kommen bei mir in Dateinamen schon vor, nach "&" werde ich nun mühsam suchen müssen, denn deine Argumentation klingt stichhaltig. Bei der Zahl an Dateien kann das noch lustig werden. Aber die langen Winterabende kommen ja auch in diesem Winter.
Sonderzeichen in Datei / Pfadnamen sind immer kritisch zu betrachten. Das Betriebssystem kann durchaus mit & im Dateinamen umgehen, aber wenn man als Entwickler nicht tierisch aufpasst und Dateinamen die man im Programm an andere Dienste übergibt, nicht sauber escaped, dann kommt es zu oft unergründbaren Fehlern.
& bedeutet unter unixoiden Systemen "führe den Befehl im Hintergrund aus". Daher -> vermeide & in Datei- und Pfadnamen
Gut zu wissen, konnte mich gar nicht mehr erinnern. Unix ist bei mir schon mehr als fünfzig Jahre her.
Nach der Löschung der betreffenden App-Container auf dem Installationspfad sind diese Fehler zwar auch nicht mehr aufgetreten, aber ich habe ungern offene Enden: Hast du vielleicht noch einen Verdacht, was die Fehlermeldung "Der Vorgang konnte nicht abgeschlossen werden. Speicher kann nicht zugewiesen werden. NSPOSIXErrorDomain 12" bedeuten könnte?
. Du kennt mich ja deswegen - wer nicht will, der hat ja schon.
