Lightroom CC, Katalog Import von Netzwerk Share

Du löst ja nicht das Rechte-Problem, wenn Du von AFP auf SMB auf umstellst.
Kann es sein, dass am Share *.DS_Store Dateien liegen?
Die können wohl auch die Ursache sein, so die Aussage eines Mac-Kollegen. Ich selbst habe davon wenig Ahnung.

moin,

isibitz schrieb:

Du löst ja nicht das Rechte-Problem, wenn Du von AFP auf SMB auf umstellst.
Kann es sein, dass am Share *.DS_Store Dateien liegen?
Die können wohl auch die Ursache sein, so die Aussage eines Mac-Kollegen. Ich selbst habe davon wenig Ahnung.

Zum Vergrößern anklicken....

ja das QNAP legt da diese *.DS_Store Dateien an. Ich hab die eben vor dem Versuch mal gelöscht, dass hat sich aber nicht ausgewirkt.

BlueByte schrieb:

ja das QNAP legt da diese *.DS_Store Dateien an.

Zum Vergrößern anklicken....

Nein, die Dateien werden von Mac angelegt. Es gab vor Jahren einen Trick, später Tool damit man diese "blöde" Dateien Dateien verhindert, später in ein separates Verzeichnis verschiebt. Das geht aber alles nicht mehr.
Und die Dateien heißen nicht *.DS_Store, sondern .DS_Store. Mit dem Punkt vorne wird dem Mac "signalisiert" es handelt sich um versteckte Datei, die man im Normalfall gar nicht sieht (außer man hat natürlich aktiviert, versteckte Dateien anzuzeigen - im Finder)

RobiWan schrieb:

Und die Dateien heißen nicht *.DS_Store, sondern .DS_Store. Mit dem Punkt vorne wird dem Mac "signalisiert" es handelt sich um versteckte Datei, die man im Normalfall gar nicht sieht (außer man hat natürlich aktiviert, versteckte Dateien anzuzeigen - im Finder)

Zum Vergrößern anklicken....

ja das ist soweit klar. ich habe Sie testweise via ssh auf dem QNAP entfernt, das hat für den Importvorgang aber keine Auswirkung gehabt.

BlueByte schrieb:

das hat für den Importvorgang aber keine Auswirkung gehabt.

Zum Vergrößern anklicken....

Was auch richtig ist. Adobe erlaubt doch kein Katalog auf einem Netzlaufwerk und damit wirst Du egal welches Protokoll genutzt wird kein Erfolg damit haben (außer es hat sich etwas verändert und ich es nicht mi habe).
Was gehen musste, wäre iSCSI, ob das mit QNAP geht... K.A

RobiWan schrieb:

Und die Dateien heißen nicht *.DS_Store, sondern .DS_Store. Mit dem Punkt vorne wird dem Mac "signalisiert" es handelt sich um versteckte Datei, die man im Normalfall gar nicht sieht (außer man hat natürlich aktiviert, versteckte Dateien anzuzeigen - im Finder)

Zum Vergrößern anklicken....

Hm. Ganz exakt müsste es ._DS_Store (erst Punkt, dann Strich) heißen, es wird eigentlich auch nix verstecktes signalisiert, sondern es handelt sich ganz ordinär um die sog. Resource Fork (inkl. Metadaten), in der MacOS aus Kompatibilitätsgründen zwecks Verständigung u.a. mit AFP- oder SMB-Volumes oder per FTP oder zur "Rettung" der Dateistrukturen und gewisser Verarbeitungsinformationen beim Umspeichern auf Non-HFS-Volumes (FAT, FAT32, exFAT, NTFS...) Eigenschaften der eigentlichen Daten- oder Executable-Datei (Data Fork) hinterlegt. Damit die von MacOS genauso komfortabel verarbeitet werden können, wie unter HFS und Nachfolgern.

In der XML-Welt würde man sowas wohl als "Sidecar" bezeichnen.

Und es ist dem NAS völlig piepegal, ob eine "._"-Datei rumfliegt: Die wird eh völlig ignoriert. Auch dem Zielsystem ist es eigentlich wurscht, weil das MacOS fehlende Resource Forks neu generiert. Das verzögert halt den Vorgang beim ersten Aufruf um ein paar Millisekunden.

Was allerdings beim "Teilen" via Netzwerk-Share nicht ignoriert wird, sind die Berechtigungen (W/R) und Freigaben. Wenn die zwischen Quell- und Zielsystem nicht exakt übereinstimmen und zum angemeldeten User (identischer Name, PW) passen, hakts oft.

Floyd Pepper schrieb:

es wird eigentlich auch nix verstecktes signalisiert

Zum Vergrößern anklicken....

Doch - unter *nix sind Dotfiles erst mal versteckt vor dem User und deswegen ohne weiteres im Finder nicht sichtbar.