Hierzu kurz meine Meinung als aktiver Netatalk Entwickler:
Hey, das ist ja schön - die Quelle direkt vor Ort. Das ist OpenSource ;-)
AFP ist ein zwar umfangreiches, aber letztzlich einfaches und vor allem genau dokumentiertes Protokoll [1]. Bis auf den Sündenfall Spotlight übers Netz seit 10.5 ist das alles sauber nachvollziehbar dargestellt. Spotlight übers Netz leider nicht, da dort halt auf serverseite Spotlight laufen müsste, was es nicht kann da der Kram Apple propietär. Daher wurden die entsprechenden Funktionen in AFP leider auch nicht dokumentiert. Wie Grouplogic das trotzdem hinbekommen hat ist mir ein Rätsel.
Spotlight ist mir sowieso egal, das ist was für Leute, die nicht aufräumen. ;-)
Was ich sagen will: In der Praxis geht es ja nicht um Dokumentation oder Lizenz, sondern darum, ob der Kram läuft. Und da gab es in der Vergangenheit Probleme, sowohl bei Apple als auch bei netatalk, weil Apple halt irgendwas ändert. Jedesmal, wenn ich bei einem Systemupdate in die Changes gucke (soweit das überhaupt von Apple dokumentiert wird), steht da irgendwas von Veränderungen in AFP.
Die allseits bekannten Desaster (Photoshop, Word, Quark) sprechen da Bände…
Für mich ist es in der Produktion der sicherste Weg, da komplett auf Apple zu setzen. Sagen wir es mal ganz böse: Selbst falls das dann schiefgeht, kann ich mit dem Finger auf Apple zeigen. Habe ich eine andere Config gewählt, bin ich dafür verantwortlich.
Dem kann allein aus einem Grund prinzipiell auch gar nicht so sein: locking. Auf Einzeplatzrechnern unnötig, auf Shares schon.
Gut - das ist klar. Wobei Apple ja auch lokal in der GUI ein Locking implementiert hat („Datei in Benutzung“), allerdings nur auf höherer Ebene, denn in der Shell kann man dann ja doch…
…aber was ich sagen wollte: Wenn so eine Datei einmal offen ist, dann kann ich lesen, schreiben, appenden, seeken. Mag jetzt noch was fehlen, aber das sind dann so die primitiven Aktionen. Ich verstehe nicht, wie so ein read/write/seek fehlschlagen kann, solange die physikalische Verbindung zum Medium steht. Solange ich keine Low-Level-Programmierung mache (die diesbezüglich in einer DTP-Applikation nix zu suchen hat), erfahre ich als Programmierer doch nicht mal, was ich da gerade ge-fopen-t habe. Im Extremfall habe ich mir MacFUSE installiert und öffne eine Datei per ftp oder ssh oder gar IMAP, und „mein“ Programm macht doch immer nix anderes als $success=fopen ($datei, READWRITE ).
Dabei haben wir einen Workaround in HEAD meist als erste implementiert. Gegenwärtig dauert leider der Weg in die Distributionen Äonen, wir arbeiten dran, auf mittelfristige Sicht kann dann Debian empfehlen, die werden ggfls. Patches auf Zuruf aufnehmen.
Das klingt gut. Ich setze auf Ubuntu, aber die sind ja Geschwister (Und benehmen sich manchmal auch so… Haarzieh… das ist mein Bagger… aber ich hatte ihn zuerst…
).
Derzeit steht da bei uns aber ohnehin keine Änderung an: Läuft - Flossen weg.
Kommerzielle Alternativen für den Produktiveinsatz aus meiner Sicht: für *nix-oide Sever HELIOS, für Windows Server ExtremeZ-IP.
Helios kenne ich nur als User und von vor 10 Jahren, lief wohl sehr gut.
Könnte mit 2.0.4 besser werden. Da gibts neue Volume Optionen um Permissions festzunageln.
Super! Danke für dein Feedback.
Gruß,
Jörg
