Helmut Gaishauser schrieb in <
news:679075fd-c8b8-4c38...@googlegroups.com>
>>> Meine Frage: ist es sinnvoller stattdessen SMB zu verwenden?
>>
>> Nein. Das wäre sogar richtig doof, das mittendrin umzustellen, denn
>> beim Zugriff per AFP und SMB werden Finder-Metadaten als auch
>> allfällige Ressourceforks völlig unterschiedlich gespeichert. In
>> Folge hast Du (Meta-)Datensalat.
>>
> Mittendrin heisst also: wenn schon Daten vorhanden sind?
Genau. Du hast mit nahezu jeder Multiprotokoll-Serverlösung immer das
Problem, wenn Du abwechselnd mit AFP und SMB vom Mac aus zugreifst,
einfach weil per SMB Finder-Metadaten und evtl. vorhandene Ressourcefork
in eine AppleDouble-Datei mit dem Präfix "._" gepackt werden, wohingegen
sie bei AFP als Teil des Protokolls transportiert werden und es Sache
des Servers ist, wie er das im FS des Servers speichert (Netatalk,
dessen sich Synology bedient, kennt da zig verschiedene Wege -- keine
Ahnung, welches Schema die nutzen)
> D.h. ein Switch ginge nur per neuem Volume und umkopieren?
Auf Basis Synology und wenn Dir diese Metadaten was wert sind, würde ich
mal sagen: ja.
> JFTR: was konkret würde denn wirklich verloren gehen? Werden
> Ressourceforks heutzutage überhaupt noch verwendet?
Zu Ressourceforks: Ja, die werden seit 10.6 extrem exzessiv seitens
Apple verwendet. Aber in völlig anderem Kontext, der übers Netzwerk
zudem keine Bedeutung hat (Apple hat in 10.6 eine transparente Datei-
kompression eingebaut, die bei großen Dateibrocken den komprimierten
Inhalt in der Resourcefork von Dateien unterbringt. Das ist ein Grund,
warum ein "nacktes" OS X zwischen 10.5 und 10.6 um IIRC ca. 2 GByte
geschrumpft ist: Weil Apple quasi alle Systemdateien komprimiert
ausliefert).
Im Kontext normaler Dateinutzung spielen Ressourceforks abseits "custom
Icon" (also buntes Bildchen zur Anhübschung der Finder-Darstellung) kaum
mehr eine Rolle.
Umso mehr aber die Metadaten -- das fängt bei so Zeugs wie Etiketten an,
geht weiter über Dateikommentare und wird in 10.9 noch ausgebaut werden,
weil das neue "Tagging" letztlich auch auf Datei-Metadaten basiert
(konkret werden alle Dateitags in Form einer Property List als Extended
Attribut -- bzw. übers Netz auf SMB-Server, die mit Filestreams umgehen
können, als entsprechender Filestream) an der Datei gespeichert. Oder
wenn das Zieldateisystem damit nicht umgehen kann, dann eben wieder in
der ._-AppleDouble-Krückendatei, die neben der eigentlichen Datei liegt.
Sowohl Apples SMB-Server als auch -Client versteht sich auch heute schon
auf so Spezialitäten, daß vieles Mac-Spezifisches einfach im "fremden"
Protokoll gemapped wird. Bspw. werden Extended Attributes zwischen zwei
Macs per SMB einfach als Filestreams übertragen. Aus EAs werden beim
Transport per AFP einfach Streams, die dann am Ziel wieder
zusammengesetzt werden und damit intakt wieder so im Dateisystem landen,
daß auch der andere Mac damit was anfangen kann. Hast Du irgendeinen
anderen SMB-Server, dann kommt's darauf an,
a) ob der überhaupt Alternate Data Streams (vulgo File Streams)
unterstützt
b) wie der die dann im Dateisystem des Servers ablegt
c) wie die auf dem Server laufende AFP-Server-Software ihrerseits mit
Extended Attributes umgeht bzw. wie diese gespeichert werden
Nur wenn alle 3 Punkte zueinander passen, dann kannst Du nach Lust und
Laune zwischen den Protokollen wechseln ohne daß Metadaten futsch gehen.
Und mit 10.9 ändert sich diesbzgl. "eigentlich" nur noch, daß auf das
effizientere SMB 2.1 umgeschalten wird und daß einige der anderen
bisherigen AFP-Spezialitäten nun auch in SMB abgebildet werden (bspw.
eben das Spotlight-Protokoll zur Suche in Dateiinhalten übers Netzwerk)
>> Dabei ist die Entscheidung pro SMB in erster Linie aufgrund
>> Performance und eben besserer Kompatibilität zum "Marktführer",
>> sprich Windows, gefallen. Und Apple hat damit gewartet, bis SMB
>> "reif" genug war, um die Appleschen Komfortfeatures dranschrauben zu
>> können.
>>
> Das klingt plausibel.
>>
>> Das hat mit den SMB-Fähigkeiten Deines NAS-Dingens aber nichts zu
>> tun. Bleibt abzuwarten, wie lange es dauert, bis Samba-Patches
>> draußen sind, die besagte Fähigkeiten auch über SMB 2.1 nachrüsten.
>>
> D.h. bis das alles ausgenutzt werden kann, muss ich warten/hoffen,
> dass Synology ihre SMB Server auf 2.1+ upgraded.
Das zum einen, zum anderen geht's um die Frage, wie das Samba mit
Filestreams umgeht (d.h. wie die im Dateisystem des Servers abgebildet
werden) und wie das mit dem von Synology verbauten Netatalk
zusammenpaßt, damit eben ein schmerzfreies Wechseln der Protokolle
möglich ist (Metadaten werden in aktuelles AFP-Versionen als EA
übertragen, müssen dann $irgendwie im FS des Servers landen und die SMB-
Server-Komponente muß dann diese dort gespeicherten EAs als Filestreams
lesen/schreiben können).
Ganz zu schweigen von Komfortfeatures wie Spotlight-Suche (ohne die ich
nicht mehr werkeln wollte). Aber keine Ahnung, ob Synology das heute
schon per AFP überhaupt anbietet.
Gruss,
Thomas, hatte witzigerweise vor 2 Stunden 'ne Videokonferenz zu genau
dem Thema mit 'nem WWDC-Besucher, der diesbzgl. ganz intensiv mit den
verantwortlichen Apple-Leuten geredet hat...