Re: OT:linuxfileserver_f_mac_win
trillan schrieb/wrote:
> ich möchte einen debian-rechner als Verbindung
> zwischen Mac (9 und X) und Win -Welt einsetzten.
>
> Ich weiss bereits, dass ich samba fuer win (auch schon erfahrung)
> und netatalk fuer mac (blutiger anfaenger) einsetzten muss/kann.
>
> hab auch schon rausgefunden, dass mac dateien zusammen mit
> einer konfigurationsdatei abspeichert.
Das sind keine Konfigurationsdateien. Dabei handelt es sich um
Resource Forks: Das MacOS speichert bisher seine Dateien immer zwei
"Forks" ab: die Daten in der Data Fork, die Resourcen (Type & Creator
sowie Programmcode, Zeichensatzinfos bei Fonts usw.) in der Resource
Fork.
Die resource Forks kann man stark vereinfacht mit dem unter Windows
(und MacOS X auch wieder) noetigen Suffix vergleichen.
> weiss zufaellig jemand wie samba mit diesen dateien umgeht will heissen:
> kann ich samba so konfigurieren, dass die konfi-dateien
> automatisch mitverschoben/-gelöscht werden?
Schoen waer's...[1]
Man kann samba lediglich anweisen, diese Dateien gegenueber den
Win-Clients "auszublenden". Schau mal in man smb.conf nach "veto
files".
> bin fuer jeden (auch allgemeinen) tip dankbar
Momentan ist die netatalk-Community recht aktiv am Entwickeln. Zum
Thema netatalk gibt es zwei engischsprachige Mailinglisten, die man
unter <http://netatalk/sourceforge.net> subscriben kann.
Ausserdem geht es in <news://de.comp.sys.mac.lokale-netze> alle
naslang um das Thema netatalk bzw. AFP.
Gruss & hth,
Christian
[1] Gibt man die gleichen Verzeichnisse mit netatalk und samba frei,
so kann man neben dem schon erwaehnten Problem der fuer Windows
bedeutungslosen Resource Forks auch noch andere Probleme bekommen:
Das MacOS referenziert Dateien und Ordner ueber eindeutige DIDs
("Directory IDs"). Hierueber wird z.B. einem Alias (auf
"windowisch": Verknuepfung) die zugehoerige Originaldatei
zugeordnet. Bis vor kurzem war es mit netatalk nicht moeglich,
diese Zuordnung ueber eine AFP-Session hinaus konsistent zu
halten. Das Verwalten der DIDs mit Hilfe der BerkeleyDB hat dem
nun abgeholfen.
Allerdings funktioniert dieser Mechanismus nur, wenn die Daten auf
dem Share auch via AFP gehaendelt werden, sprich: "Umgeht" man die
DID-"Verwaltung" (durch Kopieren via SMB oder Shell), so stellt
sich nach vermutlich schon recht kurzer Zeit ein ziemliches Chaos
aus verwaisten Resource-Forks und verwirrter DID-Verwaltung ein.
Deshalb ist es leider alles andere als ratsam, auf einer
Produktionsmaschine ein Gespann aus netatalk und samba auf die
gleichen Daten loszulassen.
Eine kommerzielle Software, die beide Rechnerwelten problemlos
versorgen kann, findet sich bei <http://www.helios.de>, kostet
aber leider ein suendhaftes Geld...
--
Christian Schmidt | Germany | christian.schmidt@chemie.uni-hamburg.de
PGP Key ID: 0x28266F2C
Reply to: