[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: