Subject: RE: Netatalk + Samba together: too many problems...

From: Michalowski Thierry <[email-masked]>
Date: Mon, 13 Nov 2000 16:32:42 +0100

short answers below...
These only imply my point of view, I'm not a "netatalk-insider"...

> 1) A Mac file with national chars (à, é, è, ù, etc.) is 
> viewed as a strange
> shortened name from Win clients. A solution has been given on 
> this list
> using iso8859-1 code page in the Netatalk and Samba volumes 
> declarations,
> but I was not able to run this solution correctly on my 
> French systems.

That should work, French locale is included into ISO8859-1 .
Check that the codepage is effectively loaded by both Samba and netatalk,
and available in the system (kernel-side).

> 2) Filenames longer than 31 chars which are allowed and managed by Win
> clients are not seen by Mac clients.

This is a limitation on the Mac side. A Mac alone cannot accept names longer
than 31 chars.
Wait for OSX...

> 3) "Lock" flag (from a Mac client point of view) and "Read 
> only" flag (from
> a Win client point of view) are not synchronized.

This seems normal to me: Macs don't have file permissions but directory
permissions only, whereas win do have both.
Another thing is that the semantics of "Locked" is not exactly the same as
"Read-only", so I doubt if this should be implemented at all.

> 4) Last but not least: renaming, deleting, copying files from 
> a Win client
> are absolutly insane operations. When you rename a file using 
> a Win client
> for example, the renaming process does not rename the .AppleDouble
> corresponding file, so the file losts its resource fork from 
> a Mac point of
> view.
> 

You should have an option available when compiling/configuring Samba :
--enable-netatalk .
This should take care of the .AppleDouble counterpart of any file when
accessed by samba.
Have a look at "Veto files" in Samba, too, to hide this "infamous" things
from the Win's users side.

> My questions:
> a) Is there any other problem using Netatalk and Samba sharing a same
> directory ?

No experience on that myself.

> b) Is exist operational solutions to avoid these problems ?

I think I gave every one that I could.

> c) Do you know if the future NTFS support on Linux will give 
> a solution for
> the point 4, allowing to store multiple file components (as 
> Mac data and
> resource forks) in "streams" of a same file (a technique used 
> by all Mac
> Servers running on NT box) ?

I would say: "never" .
GNU/Linux supports a variety of different filesystems, some of which allow
multiple streams and some not. One would not base a Linux/Unix utility on
one kind of filesystem only.
As a side note, netatalk runs on more systems than GNU/Linux only!

A smoother solution would be to implement a kernel-space netatalk, which
would allow for AppleSingle format instead of AppleDouble.

> d) I imagine to manage separatly the Netatalk volume and the 
> Samba volume,
> linking them using symbolic links and a daemon:
> let for example a Linux directory \data-a shared as a 
> Natatalk volume 'data'
> and another Linux directory \data-s shared as a Samba volume 
> 'data'; \data-s
> contains symbolic links on files which are in \data-a, and a 
> daemon manages
> the 1-1 correspondance between file naming conventions and 
> modifications by
> Mac clients in \data-a and file naming conventions and 
> modifications by Win
> clients in \data-s. Is it possible ? Is exists ?

Sharing Samba and netatalk volumes should be possible without that kind of
hassle!

HTH
Thierry Michalowski