Objekte von einem drive zum anderen kopieren ("verändern") unmöglich

[felder]

Hallo,

habe ja schon viel Idiotie bei Apple erlebt (iCloud, time machine etc), aber selten ein so idiotisches Problem wie dieses hier:

Ich möchte ein Objekt, eine Datei, eine Filmdatei von einer Festplatte auf einer anderen kopieren, als backup. In der Steinzeit kopierte man die Datei einfach handisch auf die andere Festplatte. Neuerdings soll es ja auch backup Programme wie synctwofolders dafür geben. Aber im ersten Fall (handisch) erscheint die Fehlermeldung:

- wohlbemerkt - beim kopieren einer Datei, die mitnichten von irgend einem Programm oder System verwendet werden würdde (abgesehen davon, wäre die Kopierung ja dann auch trotzdem möglich).

Im anderen Fall meldet das sync programm (automatisiert) etwas völlig anderes: Vorgang wurde nicht ausgeführt, weil Quelle älter als Ziel.
Ignoriere ich das Erstellungsdatum in den Voreinstellungen von synctwofolders, wird plötzlich überhaupt nichts mehr kopiert.

Systemeinstellung Zugriffsrechte, stimmt, aber daran liegt es nicht. Ich kann andere Dateien ohne Probleme kopieren.

Kurz: "kopieren" ist nicht "verändern", schon gar nicht, wenn es von einer auf eine andere externe Festplatte kopiert wird. Hier scheint mir der Hase im Pfeffer zu liegen. Oder?

Danke für etwaige Lösungsvorschläge.
Gruß Felder
OSX 10.15.7

 

[felder]

PS Ach ja, die zu kopierenden Dateien sind natürlich in den jeweiligen Programmen ohne Probleme zu öffnen und nicht defekt oder dergl. gar unbrauchbar.

 

[lisanet]

In der Steinzeit wusste man nich nicht, was man in der Moderne weiß. Eine Datei kann auch "inplace" zu Änderungen geöffnet sein und Programme konnten in der Steinzeit eine Datei oftmals nicht "locken" und auf exklusiven Zugriff setzen.

Daher kann es natürlich sein, dSs User aus der Steinzeit sich nicht mehr in der Gegenwart zurechtfinden.

Und nachdem niemand sieht, was du in synctwofolders eingestellt hast und nicht den Inhalt und die Eigenschaften von Quell und Zielverzeichbis kennt, kann dir auch niemand helfen. Es ist allerdings sehr wahrscheinlich, dass die App korrekt funktioniert und du womöglich was nicht verstehst

 

[felder]

Nachtrag: Testweise kontrolliert: auf dem Zielvolume sind die zu kopierenden Dateien bereits vorhanden allerdings eingegraut, also so, als ob da noch ein Kopiervorgang offen wäre, der aber nicht offen ist.

 

[felder]

In der Steinzeit wusste man nich nicht, was man in der Moderne weiß. Eine Datei kann auch "inplace" zu Änderungen geöffnet sein und Programme konnten in der Steinzeit eine Datei oftmals nicht "locken" und auf exklusiven Zugriff setzen.

Daher kann es natürlich sein, dSs User aus der Steinzeit sich nicht mehr in der Gegenwart zurechtfinden.

Und nachdem niemand sieht, was du in synctwofolders eingestellt hast und nicht den Inhalt und die Eigenschaften von Quell und Zielverzeichbis kennt, kann dir auch niemand helfen. Es ist allerdings sehr wahrscheinlich, dass die App korrekt funktioniert und du womöglich was nicht verstehst

Den Eindruck habe ich auch, nur daß die Dateien seit eh und je so kopiert wurden und das mit Gegenwart so gar nichts zu tun hat. Und ja, die "Änderung" kann ein zB nicht abgeschlossener Kopiervorgang sein, der als solcher noch "offen" ist, das wird nämlich das Problem sein. Macht ja auch extrem Sinn, abgebrochene Kopiervorgänge unabgeschlossen als Kopiervorgang systemimmanent offen zu halten. Ach ja, wenn ich die Dateien einzeln heraussuche (macht skaliert bei 1000 Dateien dann so richtig Spaß) und händisch einzeln kopiere, dann sind die offenen Kopierprozesse, die scheinbar die "Veränderung" nicht zulassen, plötzlich völlig ok und kopierbar/ersetzbar, die "Veränderung" spielt dann auf einmal keine Rolle. Nur bei der Stapelverarbeitung wird gemeckert. Alles extrem gegenwärtig sinnvoll, stimmt.

 

[felder]

Danke dennoch für das feedback. Das weiß ich zu schätzen!

 

[felder]

Eine Frage würde sich dann allenfalls noch anschließen: wie ich die gegrauten Dateien (offener Prozess) auf dem Zielvolume eliminiere.
Neustart wäre das nächstliegende, was ich in Betracht ziehen würde.

 

[lisanet]

Alles extrem gegenwärtig sinnvoll, stimmt.

Wie so oft, liegt es an individuellen Dingen, wenn es nicht läuft wie erwartet.

Wenn man aber nur mi Polemik meckert muss man sich nicht wundern, dass man Polemik zurück erhält.

Die von dir beschriebenen Probleme kenne ich nicht bei mir. Ich komme halt mit Systemen von Apple in allen Bereichen sehr gut zurecht.

 

[lisanet]

Neustart wäre das nächstliegende, was ich in Betracht ziehen würde.

Das ist der einfachste Weg. Steinzeit-erprobt.

Wenn du was lernen willst, dann befasse dich mit Terminal.app und dem Befehl "lsof". So kannst du vielleicht erkennen, ob eine App noch drauf zugreift / locked. Und dann kannst du vielleicht bei künftigen Fällen gezielter vorgehen.

 

[felder]

Wie so oft, liegt es an individuellen Dingen, wenn es nicht läuft wie erwartet.

Wenn man aber nur mi Polemik meckert muss man sich nicht wundern, dass man Polemik zurück erhält.

wohl wahr. Ich werde mich bessern.

Die von dir beschriebenen Probleme kenne ich nicht bei mir. Ich komme halt mit Systemen von Apple in allen Bereichen sehr gut zurecht.

Ich auch nicht, daher der Ärger.

OK, dann schaue ich mal im Terminal nach - wohlbemerkt, einfacher Kopiervorgang (!) - ok, ok, schon gut! (wieder so ein kleiner polemischer Ausrutscher. Ich kanns scheinbar nicht lassen)

Danke für Deine Kommentare!

Das ist der einfachste Weg. Steinzeit-erprobt.

 

[Schiffversenker]

Ich würde statt einem Rechner-Neustart erstmal den Finder neu starten. Geht schneller.
Hat bei mir bisher immer gereicht, wenn der Mac eine externe Platte nicht freieben wollte, weil angeblich noch in Benutzung.

 

[win2mac]

lösch mal die Datei auf dem Zielvolume

 

[felder]

Gemacht, getan. Danke. Der Kopiervorgang - einzeln, handisch - kann stattfinden. Im Stapel nicht. Scheint ein interner synctwofolders Bug zu sein.
Danke für Eure Antworten.