VFS to NTFS transition

[Shlomi Yaakobovich]

Ralph,

> If I am not totally missing something the code it is also 
> compatible with adouble:v2 format which is what netatalk 2 is 
> actually using to store the Mac metadata as well as some 
> private data: it is compatible because it does nothing more 
> than hide and delete adouble extra files if the corresponding 
> (data fork) file is moved (or deleted) through Samba.

I think that is correct. I did not play much with the adouble:v2 (we
switched from v1 to ads before v2 was popular), but as far as I remember
the directory format of v1 and v2 is the same.

> > 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 
> > allow the required interoperability.
> 
> So on the netatalk side: what is the functional difference between
> adouble:v2 and your adouble:sfm? Why didn't you just work 
> with adouble:v2?
> Just asking out of curiosity and in order to fully undestand 
> your implementation.

Functionality wise, everything is the same. However, the directory
structure is different like I said. The code in netatalk that deals with
SFM packs the 2 parts of the SFM resource fork (info and resource) into
one (or more if necessary) reply packet to the client. The reason for
the switch from v1/2 to sfp was not due to netatalk's needs, but rather
due to the need for interoperability with Windows application that take
advantage of Mac resource forks.

> All operations by either Mac or Windows clients (e.g. rename, delete
> etc.) shall be performed well on basis of the current netatalk
> adouble:v2 implementation. Most importantly vfs_netatalk must 
> copy and move adouble:v2 files upon SMB copy/move actions.
> 
> This and any further anhancemnet is done with the following 
> assumptions in mind:
> - primary filing protocol for Macs is AFP -- CIFS for Macs is 
> considered a bad idea in this setup
> - it is unecessary that SMB clients access Mac metadata or 
> ressource forks (as you are doing -- which applications 
> actually make use of
> that?)
> - Windows alternate data streams are stored wherever the 
> current Samba implementation and configuration likes to store 
> it, thats a totally different mapping

Unfortunately, our code is designed to work with the adouble:ads format.
If you intend to keep the adouble:v2 format, I don't think this will
help you. I can send you the code for comparison (perhaps it will give
you ideas on how to work with v2) if you want.

One thing that you've mentioned, "CIFS for Macs" is indeed a bad idea -
but it is becoming more common. Perhaps more work in samba should be
done to support it. 

Shlomi Yaakobovich, CIFS Architect - R&D Core Technologies
www.exanet.com