Synology - AFP vs. SMB

[Helmut Gaishauser]

Werte Gemeinde!

Ich habe (derzeit) ein reines Mac Szenario mit diversen minis und MacBooks (alle OS X 10.8.4) und zwei Synology Diskstations.

Derzeit bieten diese ihre Volumes rein per AFP an.

Meine Frage: ist es sinnvoller stattdessen SMB zu verwenden? Und wenn ja, warum?
Mit Mavericks wird SMB auch das bevorzugte Protokoll, wenn ich das richtig verstanden habe. Das muss ja auch einen Hintergrund haben.

danke schon mal für Eure Meinungen

cheers
hELMUT

[Thomas Kaiser]

Helmut Gaishauser schrieb in <news:11513d3f-ff86-401b...@googlegroups.com>

> Ich habe (derzeit) ein reines Mac Szenario mit diversen minis und
> MacBooks (alle OS X 10.8.4) und zwei Synology Diskstations.
>
> Derzeit bieten diese ihre Volumes rein per AFP an.
>
> 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.

> Und wenn ja, warum?

Nix ja, "nein" ;-)

> Mit Mavericks wird SMB auch das bevorzugte Protokoll, wenn ich das
> richtig verstanden habe. Das muss ja auch einen Hintergrund haben.

Das hat den Hintergrund, daß Apple dann auf SMB 2.1 anstatt SMB 1
aufsetzt und an SMB fast all das, was AFP heute gegenüber SMB überlegen
macht, dranschraubt (das Reconnect-Feature, Spotlight-Suche, "Server
Side Copies", etc. -- siehe [1] falls Du ADC-Member bist). Eine Sache,
die vorläufig auf der Strecke bleibt, ist TimeMachine-Kompatibilität
(was hoffentlich ein Indiz dafür ist, daß Apple TM übers Netzwerk
endlich mal in gscheid implementiert und den SparseBundle-Ansatz in die
Tonne tritt).

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 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.

Gruss,

Thomas

[1] https://devforums.apple.com/message/822007#822007 und
https://developer.apple.com/library/prerelease/mac/releasenotes/HardwareDrivers/RN-SMB/index.html

[Helmut Gaishauser]

Thomas Kaiser wrote:
> Helmut Gaishauser schrieb in <news:11513d3f-ff86-401b...@googlegroups.com>
>

Servus Thomas!

>
>> 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? D.h. ein Switch
ginge nur per neuem Volume und umkopieren?
JFTR: was konkret würde denn wirklich verloren gehen? Werden Ressourceforks
heutzutage überhaupt noch verwendet?

>
>
>> Und wenn ja, warum?
>
> Nix ja, "nein" ;-)
>

*gg*

>
>
> Side Copies", etc. -- siehe [1] falls Du ADC-Member bist). Eine Sache,

Danke für den Lesestoff.

>
> 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.
Wird wohl bei der alten Box nichts mehr werden, da schon länger auf DSM 3.1
festgezurrt. Aber da wäre es nicht so tragisch.

cheers
hELMUT

[Thomas Kaiser]

Helmut Gaishauser schrieb in <news:679075fd-c8b8-4c38...@googlegroups.com>

> Thomas Kaiser wrote:
>> Helmut Gaishauser schrieb in <news:11513d3f-ff86-401b...@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...

[Peter Heilingbrunner]

Thomas Kaiser <Thomas...@phg-online.de> wrote:

> 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)

> […]

> 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.

Nach meiner Erfahrung geht bei Synology per Spotlight nur die Suche nach
Dateinamen, nicht in Dateiinhalten.
Hat jemand denn schon was gehört, ob die Mavericks Tags-Funktion dann
quasi out-of-the-box auch auf solchen Netzwerkvolumes funktionieren
wird?

Denn wer momentan OpenMeta-Tags an seine Daten pappt, kann sich mit
einem Synology-NAS zwar freuen, dass diese beim Kopieren nicht verloren
gehen, aber suchen lässt sich danach nicht.

Ich hoffe dann nach Erscheinen von 10.9 auf eine Möglichkeit, die
OpenMeta Tags zu Mavericks Tags zu konvertieren – und alles wird gut. :-)

Grüße,
Peter

[Helmut Gaishauser]

Thomas Kaiser said:
>
>> 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.

Okay.

>
>> 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).

An die Kompressionsgeschichte kann ich mich erinnern. Dass das via
Ressourceforks abgehandelt wird, war mir nicht bekannt.

>
> Im Kontext normaler Dateinutzung spielen Ressourceforks abseits "custom
> Icon" (also buntes Bildchen zur Anhübschung der Finder-Darstellung) kaum
> mehr eine Rolle.

Gut.

>
> 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.

Okay, also die ganzen Sachen wie Tags, Labels, Comments etc. verwende
ich (derzeit) bei den Dateien auf der Synology eigentlich nicht.
Da ist primär meine iTunes Bibliothek (Audio & Video) drauf und sonst
noch ein paar Dinge wie die Cloudstation und Photostation.
Nur auf lokalen Volumes verwende ich diese Metadaten.

> Hast Du irgendeinen anderen SMB-Server, dann kommt's darauf an,

Ich hab nur Synologys und Macs (Clients und Server)

>
> 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)

Gut zu wissen.

>
> 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.

Die Spotlightsuche wird auch von mir sehr intensiv verwendet.
Da aber wie gesagt auf den NASen nur Dateien liegen, wo eine Inhaltssuche
eher sinnfrei ist, stört mich das derzeit nicht.

Vielen Dank für Deine extrem umfangreichen Ausführungen. So sind
Newsgroups wirklich ein Genuss!

cheers
hELMUT

[Ralph Boehme]

Hi Thomas,

ich häng mich mal an deine Ausführungen dran. :)

Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Helmut Gaishauser schrieb in <news:11513d3f-ff86-401b...@googlegroups.com>
>> Ich habe (derzeit) ein reines Mac Szenario mit diversen minis und
>> MacBooks (alle OS X 10.8.4) und zwei Synology Diskstations.
>>
>> Derzeit bieten diese ihre Volumes rein per AFP an.
>>
>> 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.

Und dazu noch das Problem das der Mac etliche am Mac gern genutzte Zeichen
(zB '/', '*'), die Windows nicht erlaubt, in die UTF8 private use range mappt.
Das Ergebnis sieht so aus: <http://oi39.tinypic.com/xeg9wm.jpg>

Wohlgemerkt betreffen die Probleme nicht OS X als kombinierten AFP/SMB
Server, sonder das Gespann AFP/Netatalk und SMB/Samba, also praktisch
alles andere inklusive NAS Schraddel.

>> Mit Mavericks wird SMB auch das bevorzugte Protokoll, wenn ich das
>> richtig verstanden habe. Das muss ja auch einen Hintergrund haben.
>
> Das hat den Hintergrund, daß Apple dann auf SMB 2.1 anstatt SMB 1
> aufsetzt und an SMB fast all das, was AFP heute gegenüber SMB überlegen
> macht, dranschraubt (das Reconnect-Feature, Spotlight-Suche, "Server
> Side Copies", etc. -- siehe [1] falls Du ADC-Member bist). Eine Sache,
> die vorläufig auf der Strecke bleibt, ist TimeMachine-Kompatibilität
> (was hoffentlich ein Indiz dafür ist, daß Apple TM übers Netzwerk
> endlich mal in gscheid implementiert und den SparseBundle-Ansatz in die
> Tonne tritt).
>
> 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.

Ich frag' mich wie man auf die Idee kommen kann dieses Protokoll fürs
Filesharing zwischen UNIX Systemem zu benutzen. SMB1 definiert ja
wenigstens noch die UNIX Extensions, stand heute mit SMB2.x ist aber immer
noch das hier:

<http://ftp.samba.org/pub/samba/cifs-cvs/ols2007-paper-smb2-french.pdf>

"Despite the addition of support for symlinks, the SMB2 protocol lacks
sufficient support for features needed by Unix and Linux clients.
Adding Unix extensions to SMB2, similar to what has been done with CIFS,
would be possible and could reuse some of the existing Unix specific info
levels."

<http://www.unixsmb2.org>

Noch nicht so richtig weit gekommen seit 2007.

> 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.

Da ists mit Patches nicht getan, da ist teils massive Entwicklungsarbeit
gefragt (bspw. für Spotlight). Im Moment ist, wie zu erwarten, bei den
NAS/Storage Herstellern wenig Problembewusstsein vorhanden, es bestehen
aber gewisse Aussichten dass sich einige finden die die entsprechende
Entwicklungsarbeit unterstützen. Synology gehört da aber wie bisher
leider eher nicht zu.

-r

[Thomas Kaiser]

Peter Heilingbrunner schrieb am 06.08.2013 in <news:heilingbrunner-949651.18372606082013@localhost>

> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>
>> 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)
>
>> […]
>
>> 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.
>
> Nach meiner Erfahrung geht bei Synology per Spotlight nur die Suche
> nach Dateinamen, nicht in Dateiinhalten.

Dann hat diese Suchart _nichts_ mit Spotlight zu tun. Denn "Spotlight"
bedeutet, daß der Server spezifische AFP-Calls kennen muß, in die Apples
Spotlight-Protokoll "eingewickelt" ist (ab 10.9 wird dieses Protokoll
dann eben auch in SMB 2 transportierbar sein, wenn der SMB-Server das
unterstützt). In Deinem Fall sucht der Mac auf dem Synology-Dings
entweder per "brute force" (d.h. durchsucht client-seitig das komplette
Netzwerkvolume nach der Zeichenfolge bzgl. Dateinamen) oder benutzt den
sog. "FPCatSearch"-Call, der die Suchbegriffe zum Server transportiert
und es dem Server überläßt, wie er die Trefferliste zustande bekommt
(idealerweise geschieht dort die Suche aus der CNID-Datenbank des
Volumes heraus, in der alle Dateinamen samt deren CNID -- Catalog Node
ID -- verzeichnet sein sollten)

http://netatalk.sourceforge.net/wiki/index.php/CatalogSearch

> Hat jemand denn schon was gehört, ob die Mavericks Tags-Funktion dann
> quasi out-of-the-box auch auf solchen Netzwerkvolumes funktionieren
> wird?

Funktionieren im Sinn der Speicherbarkeit natürlich. Die Tags sind nix
weiter als eine Property List, die in einem Extended Attribute
untergebracht wird. Diese werden entweder "flach" gespeichert (also als
AppleDouble-Datei neben der eigentlichen Datei, das "._"-Zeugs) oder
wenn der Server EAs per AFP kann (bzw. Filestreams per SMB) dann eben
"richtig". Der Knackpunkt ist aber, ob auf dem Server eine zu Spotlight
kompatible Indizierungs-Engine läuft, die alle EAs, deren Name mit
"com.apple.metadata" beginnt in einen Spotlight-Index packt und
anfragenden Clients über das proprietäre Spotlight-Protokoll aus diesem
Index heraus antwortet.

Erwarte da nicht zu viel von Synology. Spotlight kommt mit Netatalk 3.1,
die Synology-Leute unterstützen nicht aktiv das Netatalk-Projekt, hinken
von der Implementierung deutlich hinterher und es macht den Eindruck,
als ob die Mac-relevanten Sachen dort nicht so die große Priorität
haben.

Zudem ist die Implementierung einer Spotlight-Engine auf dem Server
nicht gerade trivial, siehe bspw.

http://netatalk.sourceforge.net/wiki/index.php/Spotlight

> Denn wer momentan OpenMeta-Tags an seine Daten pappt, kann sich mit
> einem Synology-NAS zwar freuen, dass diese beim Kopieren nicht
> verloren gehen, aber suchen lässt sich danach nicht.

Klar, die Indizierungs-Komponente fehlt. Und der AFP-Server (bzw. eben
ab 10.9 dann auch SMB-Server) muß entsprechde Suche im Index anbieten.

> Ich hoffe dann nach Erscheinen von 10.9 auf eine Möglichkeit, die
> OpenMeta Tags zu Mavericks Tags zu konvertieren – und alles wird gut.

Nö, dadurch wird nicht alles gut. Das ändert nichts an der Tatsache, daß
Du _auf dem Server_ eine Spotlight-kompatible Indizierungs-Engine
brauchst und Filesharing-Daemons, die daran andocken können und Apples
Spotlight-Protokoll wrappen.

Die Tags selbst sind nicht das Problem. Einmal das Filesystem nach
Dateien mit dem entsprechenden OpenMeta-EA [1] absuchen, dann ggf. die
Property List umschreiben und als 10.9-Finder-EA wieder schreiben
(lassen -- sowas macht man nicht zu Fuß sondern per Skript oder einem
der sicherlich dann zur Verfügung stehenden Tools)

Gruss,

Thomas

[1] http://ironicsoftware.com/vanillaforums/discussion/comment/4564#Comment_4564

[Thomas Kaiser]

Ralph Boehme schrieb in <news:ktsvuo$78d$1...@news.albasani.net>

> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> Helmut Gaishauser schrieb in <news:11513d3f-ff86-401b...@googlegroups.com>
>>> Ich habe (derzeit) ein reines Mac Szenario mit diversen minis und
>>> MacBooks (alle OS X 10.8.4) und zwei Synology Diskstations.
>>>
>>> Derzeit bieten diese ihre Volumes rein per AFP an.
>>>
>>> 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.
>
> Und dazu noch das Problem das der Mac etliche am Mac gern genutzte
> Zeichen (zB '/', '*'), die Windows nicht erlaubt, in die UTF8 private
> use range mappt. Das Ergebnis sieht so aus:
> <http://oi39.tinypic.com/xeg9wm.jpg>

Danke für die Ergänzung. Die Encoding-Hölle hatte ich schon wieder
erfolgreich verdrängt.

> Wohlgemerkt betreffen die Probleme nicht OS X als kombinierten AFP/SMB
> Server

Mal blöd gefragt: Wie macht Apple das? Also bspw. einen Slash
transportieren? Wenn OS X als Client sowas auf dem Server anlegen will,
prüft es dann, ob die Gegenstelle auch OS X ist (und sendet / dann auch
als /) oder erkennt das dann der SMB-Server in OS X und benennt das
krude weggemappte Zeichen dann im FS des Servers wieder in "/" um? Und
falls Letzteres, was kriegt eine Windows-Kiste kredenzt, die dann auf so
einen Ordner per OS X' SMB-Sharing zugreift?

[Umstieg auf SMB 2 als bevorzugtes Protokoll]

> Ich frag' mich wie man auf die Idee kommen kann dieses Protokoll fürs
> Filesharing zwischen UNIX Systemem zu benutzen.

Weil Apple alles, was in den offiziösen Specs fehlt, einfach "privat"
implementiert, so daß das Ganze zwischen zwei OS X mit 10.9 aufwärts
kein Thema ist (und der Rest der Welt dann die Apple-proprietären
Protokollanbauen evtl. übernimmt?)

>> 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.
>
> Da ists mit Patches nicht getan, da ist teils massive Entwicklungsarbeit
> gefragt (bspw. für Spotlight).

Naja, aber die Arbeit hat ja netafp.com schon so ziemlich erledigt,
oder? Jetzt kann man sich doch einfach dort bedienen und baut dann nur
noch den Part "Spotlight-Queries" in Samba ein?

> Im Moment ist, wie zu erwarten, bei den NAS/Storage Herstellern wenig
> Problembewusstsein vorhanden, es bestehen aber gewisse Aussichten dass
> sich einige finden die die entsprechende Entwicklungsarbeit
> unterstützen. Synology gehört da aber wie bisher leider eher nicht zu.

Und diese Verweigerungshaltung gegenüber den Mac-relevanten Sachen ist
für mich K.O.-Kriterium bzgl. Synology.

Gruss,

Thomas

[Peter Heilingbrunner]

Thomas Kaiser <Thomas...@phg-online.de> wrote:

> Dann hat diese Suchart _nichts_ mit Spotlight zu tun. Denn "Spotlight"
> bedeutet, daß der Server spezifische AFP-Calls kennen muß, in die Apples
> Spotlight-Protokoll "eingewickelt" ist (ab 10.9 wird dieses Protokoll
> dann eben auch in SMB 2 transportierbar sein, wenn der SMB-Server das
> unterstützt). In Deinem Fall sucht der Mac auf dem Synology-Dings
> entweder per "brute force" (d.h. durchsucht client-seitig das komplette
> Netzwerkvolume nach der Zeichenfolge bzgl. Dateinamen) oder benutzt den
> sog. "FPCatSearch"-Call, der die Suchbegriffe zum Server transportiert
> und es dem Server überläßt, wie er die Trefferliste zustande bekommt
> (idealerweise geschieht dort die Suche aus der CNID-Datenbank des
> Volumes heraus, in der alle Dateinamen samt deren CNID -- Catalog Node
> ID -- verzeichnet sein sollten)
>
> http://netatalk.sourceforge.net/wiki/index.php/CatalogSearch

Der Enduser (mich eingeschlossen) nennt halt die Suche an sich auf
seinem Mac „Spotlight“ (genau so wie man früher eben mit „Sherlock“
gesucht hat), egal was hinter den Kulissen abläuft.

> Nö, dadurch wird nicht alles gut. Das ändert nichts an der Tatsache, daß
> Du _auf dem Server_ eine Spotlight-kompatible Indizierungs-Engine
> brauchst und Filesharing-Daemons, die daran andocken können und Apples
> Spotlight-Protokoll wrappen.
>
> Die Tags selbst sind nicht das Problem. Einmal das Filesystem nach
> Dateien mit dem entsprechenden OpenMeta-EA [1] absuchen, dann ggf. die
> Property List umschreiben und als 10.9-Finder-EA wieder schreiben
> (lassen -- sowas macht man nicht zu Fuß sondern per Skript oder einem
> der sicherlich dann zur Verfügung stehenden Tools)

Ach menno, ich hatte mich schon so gefreut. Wenn wir da tatsächlich auf
das Engagement von Synology angewiesen sind, mache ich mir keine großen
Hoffnungen.

Danke jedenfalls für Deine Ausführungen, besonders auch der Link zu den
Ausführungen bzgl. Open Meta von dem Default-Folder-Entwickler fand ich
interessant.

Grüße,
Peter

[Thomas Kaiser]

Helmut Gaishauser schrieb am 06.08.2013 in <news:b6cs5j...@mid.individual.net>
> Thomas Kaiser said:
>>
>> (Apple hat in 10.6 eine transparente Dateikompression 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).
>
> An die Kompressionsgeschichte kann ich mich erinnern. Dass das via
> Ressourceforks abgehandelt wird, war mir nicht bekannt.

Das wird auf drei verschiedenen Wegen erledigt, je nachdem wie groß die
Datei ist:

1) große Dateien landen komprimiert in der Resource Fork (und die
Datafork ist dann leer, d.h. 0 Byte groß).

2) kleine Dateien (die komprimiert die Größe eines HFS+ Blocks -- 4096
Byte -- unterschreiten), landen komprimiert in eben so einem Extended
Attribut (und Datafork wieder mal 0 Byte groß)

3) ganz kleine Dateien landen _unkomprimiert_ in einem Extended
Attribut. Klingt komisch ist aber so. Und auch das spart
Speicherplatz, denn EAs gibt's ja eigentlich gar nicht in HFS+. Das
wurde zu Zeiten von 10.4 an HFS+ drangeschraubt und "physisch" landen
EAs im sog. "Attributes File" als "named forks". Und damit belegen
sie nur den Platz, den sie wirklich brauchen und nicht wie es bei
Data oder Ressource Forks der Fall wäre mindestens einen HFS+ Block:
4 KByte

D.h. für Apple führte angesichts der Notwendigkeit, neue FS-Features in
neuen OS-Versionen immer so einzuführen, daß das FS auch den Einsatz an
einer ggf. deutlich älteren MacOS-Version (auch prä OS X) "überlebt",
zwangsläufig dazu, für größere Dateien bzgl. Kompression auf die
altbekannten Ressourceforks zurückzugreifen. Allerdings kriegt man als
Anwender davon nichts mit, da derlei Dateien unter 10.5 und kleiner
einfach leer aussehen und ab 10.6 die transparente Kompression die
ganzen Implementierungsdetails abstrahiert.

Im Detail:

http://arstechnica.com/apple/2009/08/mac-os-x-10-6/3/

Gruss,

Thomas

[Ralph Boehme]

Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Ralph Boehme schrieb in <news:ktsvuo$78d$1...@news.albasani.net>
>> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>>> Helmut Gaishauser schrieb in <news:11513d3f-ff86-401b...@googlegroups.com>
>>>> Ich habe (derzeit) ein reines Mac Szenario mit diversen minis und
>>>> MacBooks (alle OS X 10.8.4) und zwei Synology Diskstations.
>>>>
>>>> Derzeit bieten diese ihre Volumes rein per AFP an.
>>>>
>>>> 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.
>>
>> Und dazu noch das Problem das der Mac etliche am Mac gern genutzte
>> Zeichen (zB '/', '*'), die Windows nicht erlaubt, in die UTF8 private
>> use range mappt. Das Ergebnis sieht so aus:
>> <http://oi39.tinypic.com/xeg9wm.jpg>
>
> Danke für die Ergänzung. Die Encoding-Hölle hatte ich schon wieder
> erfolgreich verdrängt.

:)

>> Wohlgemerkt betreffen die Probleme nicht OS X als kombinierten AFP/SMB
>> Server
>
> Mal blöd gefragt: Wie macht Apple das? Also bspw. einen Slash
> transportieren?

Hab ich doch gesagt, der Client mappt das in die UTF8 private range, der
Server macht dann damit was er will. Samba speichert "as is", OS X SMB
Server konvertiert zurück.

ASCII | Samba | Netatalk
-------------------------------------------
/ | 0xef 0x80 0xa6 | :
| | 0xef 0x80 0xa7 | |
* | 0xef 0x80 0xa1 | *
\ | 0xef 0x80 0xa2 | \

> Wenn OS X als Client sowas auf dem Server anlegen will,
> prüft es dann, ob die Gegenstelle auch OS X ist (und sendet / dann auch

> als /) ...

Nein, afaik wird immer gemappt.

> ... oder erkennt das dann der SMB-Server in OS X und benennt das

> krude weggemappte Zeichen dann im FS des Servers wieder in "/" um?

Genau.

> Und
> falls Letzteres, was kriegt eine Windows-Kiste kredenzt, die dann auf so
> einen Ordner per OS X' SMB-Sharing zugreift?

Was auch immer Windows als Platzhalterzeichen für Zeichen der private
range verwendet.

> [Umstieg auf SMB 2 als bevorzugtes Protokoll]
>> Ich frag' mich wie man auf die Idee kommen kann dieses Protokoll fürs
>> Filesharing zwischen UNIX Systemem zu benutzen.
>
> Weil Apple alles, was in den offiziösen Specs fehlt, einfach "privat"

> implementiert, ...

Nö. Was es nicht gibt fliegt raus, chmod bspw. Hat per SMB2 keinen Effekt
und taucht im Protokollstream gar nicht auf, gerade nochmal nachgeschaut.
Kein UNIX mode weit und breit, weder beim abfragen vom Server, noch
setzen. "Lediglich" die effektive "maximum access mask" wird vom Server
an den Client geschickt in GetInfo Responses, also sozusagen die
effektiven Rechte in ACL Granularität.

>>> 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.
>>
>> Da ists mit Patches nicht getan, da ist teils massive Entwicklungsarbeit
>> gefragt (bspw. für Spotlight).
>
> Naja, aber die Arbeit hat ja netafp.com schon so ziemlich erledigt,
> oder? Jetzt kann man sich doch einfach dort bedienen und baut dann nur
> noch den Part "Spotlight-Queries" in Samba ein?

Nix einfach, das steckt in einem speziellen neuen SMB RPC Protokoll
und die Anbindung an Tracker ist aufwändig. :)

Gruß,
Ralph

[Thomas Kaiser]

Ralph Boehme schrieb in <news:kttira$dpe$1...@news.albasani.net>

> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> Ralph Boehme schrieb in <news:ktsvuo$78d$1...@news.albasani.net>
>>>

> [...]

>> ... oder erkennt das dann der SMB-Server in OS X und benennt das
>> krude weggemappte Zeichen dann im FS des Servers wieder in "/" um?
>
> Genau.
>
>> Und falls Letzteres, was kriegt eine Windows-Kiste kredenzt, die dann
>> auf so einen Ordner per OS X' SMB-Sharing zugreift?
>
> Was auch immer Windows als Platzhalterzeichen für Zeichen der private
> range verwendet.

Aber ist es ja dann gar nicht mehr, wenn OS X' SMB-Server einen / auch
als / (bzw. :) im Dateisystem ablegt? Naja, mal nachgucken, was
passiert, wenn mal Zeit/Lust vorhanden, 10.9 in Stellung zu bringen und
'ne Windows-VM hochzufahren...

>> [Umstieg auf SMB 2 als bevorzugtes Protokoll]
>>> Ich frag' mich wie man auf die Idee kommen kann dieses Protokoll fürs
>>> Filesharing zwischen UNIX Systemem zu benutzen.
>>
>> Weil Apple alles, was in den offiziösen Specs fehlt, einfach "privat"
>> implementiert, ...
>
> Nö. Was es nicht gibt fliegt raus, chmod bspw. Hat per SMB2 keinen
> Effekt und taucht im Protokollstream gar nicht auf, gerade nochmal
> nachgeschaut. Kein UNIX mode weit und breit, weder beim abfragen vom
> Server, noch setzen. "Lediglich" die effektive "maximum access mask"
> wird vom Server an den Client geschickt in GetInfo Responses, also
> sozusagen die effektiven Rechte in ACL Granularität.

Oha, das ist natürlich starker Tobak. Bleibt zu hoffen, daß das noch was
kommt. Helmut meinte gestern bei den Helios-internen Tests von 10.9
hätten sie auf der Basis der Prerelease-Versionen eh arge Zweifel, ob
das in der Form mit SMB2 funktioniert, weil selbst zwischen zwei 10.9-
Kiste so viel Essentielles (noch) nicht funktioniert.

>>>> 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.
>>>
>>> Da ists mit Patches nicht getan, da ist teils massive
>>> Entwicklungsarbeit gefragt (bspw. für Spotlight).
>>
>> Naja, aber die Arbeit hat ja netafp.com schon so ziemlich erledigt,
>> oder? Jetzt kann man sich doch einfach dort bedienen und baut dann
>> nur noch den Part "Spotlight-Queries" in Samba ein?
>
> Nix einfach, das steckt in einem speziellen neuen SMB RPC Protokoll
> und die Anbindung an Tracker ist aufwändig. :)

OK, aber trotzdem gehe ich Stand jetzt davon aus, daß netafp.com da
einen Vorteil hat und daß es sich für die Hersteller irgendwelcher NAS-
Eimer anläßlich 10.9 lohnen dürfte, sich dort Knowhow bzw. Unterstützung
einzukaufen?

Anläßlich der default-Reihenfolge, in der 10.9 das zu verwendende
Protokoll auswählt, wenn man nur die IP-Adresse angibt (vor 10.9 erst
AFP, dann SMB1 -- ab 10.9 erst SMB2, dann AFP, dann SMB1) stehen ja die
Chancen recht "gut", daß bei Multi-Protokoll-Servern ab Samba 3.6 und
"max protocol = SMB2" mit Upgrade der Clients auf 10.9 das (Metadaten-)
Chaos ausbricht :-)

Gruss,

Thomas

[Ralph Boehme]

Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Ralph Boehme schrieb in <news:kttira$dpe$1...@news.albasani.net>
>> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>>> Ralph Boehme schrieb in <news:ktsvuo$78d$1...@news.albasani.net>
>>>>
>> [...]
>>> ... oder erkennt das dann der SMB-Server in OS X und benennt das
>>> krude weggemappte Zeichen dann im FS des Servers wieder in "/" um?
>>
>> Genau.
>>
>>> Und falls Letzteres, was kriegt eine Windows-Kiste kredenzt, die dann
>>> auf so einen Ordner per OS X' SMB-Sharing zugreift?
>>
>> Was auch immer Windows als Platzhalterzeichen für Zeichen der private
>> range verwendet.
>
> Aber ist es ja dann gar nicht mehr, wenn OS X' SMB-Server einen / auch
> als / (bzw. :) im Dateisystem ablegt? Naja, mal nachgucken, was
> passiert, wenn mal Zeit/Lust vorhanden, 10.9 in Stellung zu bringen und
> 'ne Windows-VM hochzufahren...

Grad mal mit Win8 probiert und siehe da, '/' und '*' problemlos richtig
angezeigt. Was auch immer genau da im Hintergrund passiert, auch
angesichts der Tatsache dass beides laut MSDN immer noch reserved
characters sind.

<http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx>

Wireshark wollte auf der relevanten 10.9 Kiste eben nicht anspringen, daher
kann ich grad nicht mit Details dienen (auf einem anderen 10.9 Rechner
läuft Wireshark aber durchaus).

>
>>> [Umstieg auf SMB 2 als bevorzugtes Protokoll]
>>>> Ich frag' mich wie man auf die Idee kommen kann dieses Protokoll fürs
>>>> Filesharing zwischen UNIX Systemem zu benutzen.
>>>
>>> Weil Apple alles, was in den offiziösen Specs fehlt, einfach "privat"
>>> implementiert, ...
>>
>> Nö. Was es nicht gibt fliegt raus, chmod bspw. Hat per SMB2 keinen
>> Effekt und taucht im Protokollstream gar nicht auf, gerade nochmal
>> nachgeschaut. Kein UNIX mode weit und breit, weder beim abfragen vom
>> Server, noch setzen. "Lediglich" die effektive "maximum access mask"
>> wird vom Server an den Client geschickt in GetInfo Responses, also
>> sozusagen die effektiven Rechte in ACL Granularität.
>
> Oha, das ist natürlich starker Tobak. Bleibt zu hoffen, daß das noch was
> kommt. Helmut meinte gestern bei den Helios-internen Tests von 10.9
> hätten sie auf der Basis der Prerelease-Versionen eh arge Zweifel, ob
> das in der Form mit SMB2 funktioniert, weil selbst zwischen zwei 10.9-
> Kiste so viel Essentielles (noch) nicht funktioniert.

Echt, die haben noch mehr entdeckt? :)

>>>>> 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.
>>>>
>>>> Da ists mit Patches nicht getan, da ist teils massive
>>>> Entwicklungsarbeit gefragt (bspw. für Spotlight).
>>>
>>> Naja, aber die Arbeit hat ja netafp.com schon so ziemlich erledigt,
>>> oder? Jetzt kann man sich doch einfach dort bedienen und baut dann
>>> nur noch den Part "Spotlight-Queries" in Samba ein?
>>
>> Nix einfach, das steckt in einem speziellen neuen SMB RPC Protokoll
>> und die Anbindung an Tracker ist aufwändig. :)
>
> OK, aber trotzdem gehe ich Stand jetzt davon aus, daß netafp.com da
> einen Vorteil hat und daß es sich für die Hersteller irgendwelcher NAS-
> Eimer anläßlich 10.9 lohnen dürfte, sich dort Knowhow bzw. Unterstützung
> einzukaufen?

Seh ich auch so, mal sehen ob das die NAS OEMs auch so sehen.

> Anläßlich der default-Reihenfolge, in der 10.9 das zu verwendende
> Protokoll auswählt, wenn man nur die IP-Adresse angibt (vor 10.9 erst
> AFP, dann SMB1 -- ab 10.9 erst SMB2, dann AFP, dann SMB1) stehen ja die
> Chancen recht "gut", daß bei Multi-Protokoll-Servern ab Samba 3.6 und
> "max protocol = SMB2" mit Upgrade der Clients auf 10.9 das (Metadaten-)
> Chaos ausbricht :-)

Definitiv.

Gruß,
Ralph

[Ralph Boehme]

Nachtrag, Wireshark sagt: U+f021 und U+f022, also private use area. Wie
Windows (in dem Fall wie gesagt 8) es schafft das "richtig" anzuzeigen
entzieht sich derzeit meinen Kenntnissen.

-r

[Thomas Kaiser]

Ralph Boehme schrieb am 07.08.2013 in <news:ktttdc$5cn$1...@news.albasani.net>

> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>> Ralph Boehme schrieb in <news:kttira$dpe$1...@news.albasani.net>
>>> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>>>> Ralph Boehme schrieb in <news:ktsvuo$78d$1...@news.albasani.net>
>>>>>
>>> [...]
>>>> ... oder erkennt das dann der SMB-Server in OS X und benennt das
>>>> krude weggemappte Zeichen dann im FS des Servers wieder in "/" um?
>>>
>>> Genau.
>>>
>>>> Und falls Letzteres, was kriegt eine Windows-Kiste kredenzt, die
>>>> dann auf so einen Ordner per OS X' SMB-Sharing zugreift?
>>>
>>> Was auch immer Windows als Platzhalterzeichen für Zeichen der
>>> private range verwendet.
>>
>> Aber ist es ja dann gar nicht mehr, wenn OS X' SMB-Server einen /
>> auch als / (bzw. :) im Dateisystem ablegt? Naja, mal nachgucken, was
>> passiert, wenn mal Zeit/Lust vorhanden, 10.9 in Stellung zu bringen
>> und 'ne Windows-VM hochzufahren...
>
> Grad mal mit Win8 probiert und siehe da, '/' und '*' problemlos
> richtig angezeigt.

> [...]

> Nachtrag, Wireshark sagt: U+f021 und U+f022, also private use area.
> Wie Windows (in dem Fall wie gesagt 8) es schafft das "richtig"
> anzuzeigen entzieht sich derzeit meinen Kenntnissen.

Und wenn Du Dir als Verzeichnislisting in bspw. Perl holst, wie landet
das Zeichen dann im Dateinamen?

>>> Nö. Was es nicht gibt fliegt raus, chmod bspw. Hat per SMB2 keinen
>>> Effekt und taucht im Protokollstream gar nicht auf, gerade nochmal
>>> nachgeschaut. Kein UNIX mode weit und breit, weder beim abfragen vom
>>> Server, noch setzen. "Lediglich" die effektive "maximum access mask"
>>> wird vom Server an den Client geschickt in GetInfo Responses, also
>>> sozusagen die effektiven Rechte in ACL Granularität.
>>
>> Oha, das ist natürlich starker Tobak. Bleibt zu hoffen, daß das noch
>> was kommt. Helmut meinte gestern bei den Helios-internen Tests von
>> 10.9 hätten sie auf der Basis der Prerelease-Versionen eh arge
>> Zweifel, ob das in der Form mit SMB2 funktioniert, weil selbst
>> zwischen zwei 10.9- Kiste so viel Essentielles (noch) nicht
>> funktioniert.
>
> Echt, die haben noch mehr entdeckt? :)

Er ist nicht groß ins Detail gegangen ließ aber durchblicken, daß er
SMB2 vom Start weg erstmal nicht für einsatzfähig hält. Das werden aber
viele Mac-Anwender nach den guten Erfahrungen mit frühen 10.8-Versionen
sicher anders sehen. Und dann sehe ich eine kleine Problemlawine abgehen
falls Anwender/Admins auf die doofe Idee kommen, auf einmal SMB zu
präferieren.

Gruss,

Thomas

[Ralph Boehme]

Thomas Kaiser <Thomas...@phg-online.de> wrote:
> Ralph Boehme schrieb am 07.08.2013 in <news:ktttdc$5cn$1...@news.albasani.net>
>> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>>> Ralph Boehme schrieb in <news:kttira$dpe$1...@news.albasani.net>
>>>> Thomas Kaiser <Thomas...@phg-online.de> wrote:
>>>>> Und falls Letzteres, was kriegt eine Windows-Kiste kredenzt, die
>>>>> dann auf so einen Ordner per OS X' SMB-Sharing zugreift?
>>>>
>>>> Was auch immer Windows als Platzhalterzeichen für Zeichen der
>>>> private range verwendet.
>>>
>>> Aber ist es ja dann gar nicht mehr, wenn OS X' SMB-Server einen /
>>> auch als / (bzw. :) im Dateisystem ablegt? Naja, mal nachgucken, was
>>> passiert, wenn mal Zeit/Lust vorhanden, 10.9 in Stellung zu bringen
>>> und 'ne Windows-VM hochzufahren...
>>
>> Grad mal mit Win8 probiert und siehe da, '/' und '*' problemlos
>> richtig angezeigt.
>> [...]
>> Nachtrag, Wireshark sagt: U+f021 und U+f022, also private use area.
>> Wie Windows (in dem Fall wie gesagt 8) es schafft das "richtig"
>> anzuzeigen entzieht sich derzeit meinen Kenntnissen.
>
> Und wenn Du Dir als Verzeichnislisting in bspw. Perl holst, wie landet
> das Zeichen dann im Dateinamen?

als '?', scheint aber eher ein Problem der Darstellung in cmd.exe zu sein.

---8<---
$ cat ls.pl
#!/usr/bin/perl
my $dir = 'Z:/dir/';
opendir(DIR, $dir) or die $!;
while (my $file = readdir(DIR)) {
next if ($file =~ m/^\./);
print "$file\n";
}
closedir(DIR);
$
---8<---

---8<---
Z:\dir>ls.pl
colon?
ls.pl
slash?
t?st.txt
---8<---

Ein Testdokument auf dem Mac als "t*st.txt" gespeichert lässt sich am
Windows 8 Rechner problemlos öffnen, ändern und speichern.

>>>> Nö. Was es nicht gibt fliegt raus, chmod bspw. Hat per SMB2 keinen
>>>> Effekt und taucht im Protokollstream gar nicht auf, gerade nochmal
>>>> nachgeschaut. Kein UNIX mode weit und breit, weder beim abfragen vom
>>>> Server, noch setzen. "Lediglich" die effektive "maximum access mask"
>>>> wird vom Server an den Client geschickt in GetInfo Responses, also
>>>> sozusagen die effektiven Rechte in ACL Granularität.
>>>
>>> Oha, das ist natürlich starker Tobak. Bleibt zu hoffen, daß das noch
>>> was kommt. Helmut meinte gestern bei den Helios-internen Tests von
>>> 10.9 hätten sie auf der Basis der Prerelease-Versionen eh arge
>>> Zweifel, ob das in der Form mit SMB2 funktioniert, weil selbst
>>> zwischen zwei 10.9- Kiste so viel Essentielles (noch) nicht
>>> funktioniert.
>>
>> Echt, die haben noch mehr entdeckt? :)
>
> Er ist nicht groß ins Detail gegangen ließ aber durchblicken, daß er
> SMB2 vom Start weg erstmal nicht für einsatzfähig hält.

Ach der Helmut.

Gruß,
Ralph

[Fritz]

Am 06.08.13 15:23, schrieb Thomas Kaiser:

>> >Mit Mavericks wird SMB auch das bevorzugte Protokoll, wenn ich das
>> >richtig verstanden habe. Das muss ja auch einen Hintergrund haben.
> Das hat den Hintergrund, daß Apple dann auf SMB 2.1 anstatt SMB 1
> aufsetzt und an SMB fast all das, was AFP heute gegenüber SMB überlegen
> macht, dranschraubt (das Reconnect-Feature, Spotlight-Suche, "Server
> Side Copies", etc. -- siehe [1] falls Du ADC-Member bist). Eine Sache,
> die vorläufig auf der Strecke bleibt, ist TimeMachine-Kompatibilität
> (was hoffentlich ein Indiz dafür ist, daß Apple TM übers Netzwerk
> endlich mal in gscheid implementiert und den SparseBundle-Ansatz in die
> Tonne tritt).
>
> 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 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.

Bedeutet das nun auch, wenn man auf Maverik upgraden und sich eine NAS
kaufen will, eventuell noch abzuwarten, besonders wenn dieses Vorhaben
nicht besonders dringlich ist?

Das würde auch bedeuten, dass nicht Apple Geräte - wie TV Empfänger,
Audio NetStreaming DAC's, usw. mit Shares dieser einen NAS besser
umgehen könnten.

--
Fritz

[Marc Stibane]

Fritz <frit...@gmx-topmail.de> wrote:

> Bedeutet das nun auch, wenn man auf Maverik upgraden und sich eine NAS
> kaufen will, eventuell noch abzuwarten, besonders wenn dieses Vorhaben
> nicht besonders dringlich ist?

Im Prinzip ja. Wobei man sich keine Hoffnung machen sollte, dass das
dieses Jahr noch irgendein NAS-Hersteller funktionierend eingebaut
bekommt.

> Das w�rde auch bedeuten, dass nicht Apple Ger�te - wie TV Empf�nger,

> Audio NetStreaming DAC's, usw. mit Shares dieser einen NAS besser

> umgehen k�nnten.

Jupp, das war wohl der Grund, warum Apple das Pferd wechselt.

--
In a world without walls and fences,
who needs windows and gates?

[Fritz]

Am 14.08.13 16:10, schrieb Marc Stibane:

> Im Prinzip ja. Wobei man sich keine Hoffnung machen sollte, dass das
> dieses Jahr noch irgendein NAS-Hersteller funktionierend eingebaut
> bekommt.

Ich habe keine Eile damit, ist nur eine Planung - eine Quelle für alle
Geräte.

>> >Das würde auch bedeuten, dass nicht Apple Geräte - wie TV Empfänger,

>> >Audio NetStreaming DAC's, usw. mit Shares dieser einen NAS besser

>> >umgehen könnten.

> Jupp, das war wohl der Grund, warum Apple das Pferd wechselt.

Kommt etwa doch ein Apple TV?

Loewe wär noch immer zu haben
<http://www.heise.de/newsticker/meldung/Seehofer-stellt-Staatsbuergschaft-fuer-Loewe-in-Aussicht-1934783.html>

--
Fritz

[Thomas Kaiser]

Marc Stibane schrieb am 14.08.2013 in <news:1l7loua.1g3...@marc.my-fqdn.de>

> Fritz <frit...@gmx-topmail.de> wrote:
>
>> Bedeutet das nun auch, wenn man auf Maverik upgraden und sich eine
>> NAS kaufen will, eventuell noch abzuwarten, besonders wenn dieses
>> Vorhaben nicht besonders dringlich ist?
>
> Im Prinzip ja. Wobei man sich keine Hoffnung machen sollte, dass das
> dieses Jahr noch irgendein NAS-Hersteller funktionierend eingebaut
> bekommt.

Vor allem sollte man sich tunlichst mal gar keine Hoffnungen machen, daß
die diversen NAS-Hersteller überhaupt von sich aus verstehen, welch
Aufgabe da vor ihnen liegt, wenn sie das denn genauso wie Apple selbst
umsetzen wollten.

Es gilt, all das, was jetzt nur mit AFP funktioniert (Spotlight-Suche,
Reconnect, etc.) auch über SMB abzubilden *und* einen schmerzfreien bzw.
reibungslosen Wechsel des Protokolls beim Zugriff auf identische Dateien
zu ermöglichen.

Und das involviert:

- Windows' Filestreams in Mac-EAs dynamisch umzusetzen

- Encoding-Problematiken auszuräumen (Zugriff auf Dateien mit Umlauten,
Sonderzeichen sowie den "superbösen" Zeichen, die Windows zum
Scheitern bringen, müssen über beide Protokolle identisch ausfallen
*und* ggf. Windows-SMB-Clients dürfen auch nicht drüber stolpern)

- Spotlight-Indizierung für Dateien, die per SMB daherrumpeln und eben
Implementierung der SMB-Spotlight-Variante

- all der Rest wie Reconnect, etc.

Wenn man sich anschaut, wie NAS-Hersteller das heute handhaben -- grad
die im Betreff erwähnte Firma -- dann klatschen die halt alles an Code,
der gratis zur Verfügung steht (hey, OpenSource heißt ja "kost nix")
irgendwie zusammen, kleben 'ne Management-GUI dran und fertig. Daß die
Implementierung von Fileservices für Mac über zwei grundverschiedene
Protokolle in funktionierend, deutlich über den Ansatz hinausgeht,
werden sie evtl. erst lernen (müssen). Und das wird dauern...

>> Das würde auch bedeuten, dass nicht Apple Geräte - wie TV Empfänger,

>> Audio NetStreaming DAC's, usw. mit Shares dieser einen NAS besser

>> umgehen könnten.

>
> Jupp, das war wohl der Grund, warum Apple das Pferd wechselt.

Was? Wieso das denn? Um auf irgendwelchen Consumer-Elektronik-Schraddel
per SMB zuzugreifen, braucht man doch nicht auf _Serverseite_ ansetzen
und Anbauten ans Protokoll entwickeln, die den AFP-Komfort auch über SMB
ermöglichen.

Gruss,

Thomas

[Uwe Wunderlich]

Helmut Gaishauser <6ofe...@web.de> wrote:

> Meine Frage: ist es sinnvoller stattdessen SMB zu verwenden?

Hab's versucht: Ist langsamer als AFP...

--
((( Klobi )))
_____________________________________________________________________

[Fritz]

Am 17.08.13 13:08, schrieb Uwe Wunderlich:

> Helmut Gaishauser<6ofe...@web.de> wrote:
>
>> >Meine Frage: ist es sinnvoller stattdessen SMB zu verwenden?
> Hab's versucht: Ist langsamer als AFP...

In welcher Hinsicht?

Bei der Datenübertragung? Oder ...?

--
Fritz

[Thomas Kaiser]

Fritz schrieb am 18.08.2013 in <news:5210F6D6...@uta.fritz-fqdn.dd-dns.de>

> Am 17.08.13 13:08, schrieb Uwe Wunderlich:
>> Helmut Gaishauser<6ofe...@web.de> wrote:
>>
>>> >Meine Frage: ist es sinnvoller stattdessen SMB zu verwenden?
>> Hab's versucht: Ist langsamer als AFP...

Komplett ohne Aussagekraft so lange nicht wenigstens ein klein wenig von
den Randbedingungen mit genannt werden (welche OS X Version, was wird
als SMB-Server benutzt)

> In welcher Hinsicht?
>
> Bei der Datenübertragung? Oder ...?

Zuerstmal natürlich _Stand jetzt_ bei der Datenübertragung. Historisch
gesehen ist da AFP immer schnelle als SMB gewesen solange der SMB-Server
entsprechend primitiv ist. Mit 10.9, modernen SMB-Servern und SMB2 (ja,
alle NAS-Besitzer dürfen sich wieder entspannt zurücklehnen -- ihr seid
außen vor) wird sich das aber ändern. Aus diversen Gründen:

- bei großen Dateien kommt zum Tragen, daß in SMB2 dynamisch die Größe
der Datenbrocken, die durchs Netz geschoben werden (und immer einer
Empfangsquittung bedürfen -- jetzt mal sehr laienhaft gesprochen)
adaptiert werden kann. Da sind viel größere Brocken möglich als heute
mit AFP zumeist üblich (dort ist die sog. DSI Block Size, die IIRC der
Server fix vorgibt, das Ausschlaggebende)

- bei kleinen Dateien kann sich der Client das Verpacken von EAs in
AppleDouble-Dateien sparen, wenn der Server Filestreams beherrscht. Es
entsteht dann pro Datei auf dem Mac nicht zwei auf dem SMB-Server
sondern es wird einfach die Datei plus 1-n Streams geschrieben/
gelesen (und das noch dazu in einem Request anstatt deren vieler)

- weitere bislang nur per AFP verfügbare Goodies werden dann ebenfalls
von Apple implementiert (bspw. "server side copies" -- wenn der Client
Dateien von einer Stelle auf dem Server zu einer anderen kopieren
will, dann müssen die Daten nicht durchs Netz zum Client und zurück
sondern der Client sagt einfach dem Server "Mach mal" und das findet
alles lokal auf dem Server statt). Bzgl. weiteren Verbesserungen siehe
[1] -- wohlgemerkt hat man davon nur was, wenn es auf Client- und auf
Server-Seite implementiert wird... d.h. der typische NAS-User wird da
die nächsten Jahre genau gar nix 'von haben.

Andere Sachen, die über SMB _bislang_ deutlich lahmer sind, sind bspw.
die Suche nach Dateien bzw. Dateiinhalten. Per AFP Spotlight, per SMB
muß man in jede Datei einzeln hineinschauen bzw. blöde Hacks anwenden
und in regelmäßigen Abständen vom Client aus eine lokale Indizierung des
Server-Laufwerks anstoßen. Das ändert sich natürlich dann auch, wenn man
einen SMB2-fähigen Server mit Spotlight-Funktionalität an Bord hat (once
again: Eben nicht das typische 08/15- NAS-Dingens)

Gruss,

Thomas

[1] frei nach der Pre-Release-Entwickler-Doku:

- Implemented Compounded Requests to improve performance
- Larger Read/Write/Transaction I/O sizes are used to improve
performance
- Client will issue multiple read or write requests to improve
performance
- Added Server Side Copies (OS X SMB Client <-> OS X/Windows SMB
File Server)

[Uwe Wunderlich]

Fritz <frit...@gmx-topmail.de> wrote:

> >> >Meine Frage: ist es sinnvoller stattdessen SMB zu verwenden?
> > Hab's versucht: Ist langsamer als AFP...
>
> In welcher Hinsicht?
>

> Bei der Daten�bertragung? Oder ...?

Nat�rlich bei der Daten�bertragung. Was gibt's noch?

[Fritz]

Am 21.08.13 06:41, schrieb Uwe Wunderlich:
> Natürlich bei der Datenübertragung. Was gibt's noch?

Lies z.B. die parallele AW von Thomas


--
Fritz