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


Subject: RE: Netatalk + Samba together: too many problems...
From: Jonathan Newman (jnewman@mudpup.com)
Date: Mon Nov 13 2000 - 10:57:07 EST


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

This is a limitation of both the MacOS and netatalk. It has been
suggested that the names of files for files > 31 characters get
remapped. This has a handful of issues associated with it, and is a
more complicated problem than it seems.

> 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 is a problem with Samba. Samba maintains its own concept of file
locking, avoiding the native locking mechanisms for speed. I believe
the Samba team has plans to change this.

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

I thought compiling Samba with the "netatalk" option solved some of
these issues.

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

We use them here for the same shares. We don't have a lot of
problems. One of the "tricks" is to set up the veto files on Samba so
that the windows users don't accidentally delete the
.AppleDouble/.AppleDesktop/Icon files:

veto files = /.AppleDouble/.bin/.AppleDesktop/Network Trash
Folder/Icon?/TheFindByContentFolder/Temporary
Items/TheVolumeSettingsFolder/

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

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

If I undersant correctly, you can use an HFS volume on the linux box
to accomplish exactly this. I believe the .AppleDouble structures are
supposed to mirror the interface to the hfs volume manipulation of
resource forks. Unfortunately, I don't believe there is support for
HFS+ which means only volumes up to 2GB volumes are supported. I
don't know if this all is exactly correct, but it is what I have
surmised after looking through the netatalk code.

Jon



This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:37 EST