On Apr 25, 2008, at 10:43 AM, Ralph B=F6hme wrote:
> Shlomi,
> thank you for you detailed description. Before I reply with a =20
> description of what I have in mind regarding netatalk<->samba =20
> interop I have some comments and questions:
> Am 24.04.2008 um 15:03 schrieb Shlomi Yaakobovich:
>> In Exanet we use a modified vfs_netatalk object. We call it =20
>> vfs_ads. It
>> includes possible some of the enhancements you are referring to.
>> As you might know, the vfs_netatalk code is compatible with the
>> adouble:v1 format. In short, this format saves Macintosh Resource =20
>> forks
>> under the .AppleDouble folder. Our older tests using this format were
>> quite ok, we used it for quite some time.

> If I am not totally missing something the code it is also compatible =20=

> with adouble:v2 format which is what netatalk 2 is actually using to =20=

> store the Mac metadata as well as some private data: it is =20
> compatible because it does nothing more than hide and delete adouble =20=

> extra files if the corresponding (data fork) file is moved (or =20
> deleted) through Samba.
>> However, we wanted to increase interoperability, and we discovered =20=

>> that
>> Microsoft treats Resource Forks the same way it handles Resource =20
>> forks.
>> The first stage was to develop the adouble:ads format, and also =20
>> change
>> vfs_netatalk to vfs_ads. The new functionality now saves the =20
>> Alternate
>> Data Streams in the same directory as the Macintsh Resource forks.
>> Moreover, all operations by either Mac or Windows clients (e.g. =20
>> rename,
>> delete etc.) are performed well on files with whichever attached
>> Resource Fork or Aletrnate Data streams.
>> Later work was designed to allow Windows clients/application actual
>> access to the data inside the resource fork, for example in order to
>> show the icon of the picture. This lead to the development of the
>> adouble:sfm format in netatalk and to the appropriate changes in
>> vfs_ads. Resource Forks are separated into two files in this format:
>> AFP_Resource and AFP_AfpInfo. This has its side effects, but does =20
>> allow
>> the required interoperability.

> So on the netatalk side: what is the functional difference between =20
> adouble:v2 and your adouble:sfm? Why didn't you just work with =20
> adouble:v2?
> Just asking out of curiosity and in order to fully undestand your =20
> implementation.
>> We can share the code of course, it is GPL after all ! But the =20
>> code has
>> changed quite much from the vfs_netatalk, and does not compile =20
>> without
>> our changes to samba (which I am not sure you want). However, it is =20=

>> in
>> our best interest that our changes will eventually come back to the
>> samba code. I would like to know exactly which changes you have had =20=

>> in
>> mind, ...

> All operations by either Mac or Windows clients (e.g. rename, delete =20=

> etc.) shall be performed well on basis of the current netatalk =20
> adouble:v2 implementation. Most importantly vfs_netatalk must copy =20
> and move adouble:v2 files upon SMB copy/move actions.
> This and any further anhancemnet is done with the following =20
> assumptions in mind:
> - primary filing protocol for Macs is AFP -- CIFS for Macs is =20
> considered a bad idea in this setup
> - it is unecessary that SMB clients access Mac metadata or ressource =20=

> forks (as you are doing -- which applications actually make use of =20
> that?)

These two assumptions are bogus. The 10.5 smbfs client does natively =20
propagate Mac metadata and resource forks across SMB. It provides a =20
user experience that is virtually indistinguishable from AFP. If the =20
SMB server can't support support these, then the client will fall back =20=

to using ._ files.

> - Windows alternate data streams are stored wherever the current =20
> Samba implementation and configuration likes to store it, thats a =20
> totally different mapping
> Regards,
> -Ralph