VFS to NTFS transition
Ralph Böhme
lists at supported.de
Fri Apr 25 17:43:57 GMT 2008
Shlomi,
thank you for you detailed description. Before I reply with a
description of what I have in mind regarding netatalk<->samba 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 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
> 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
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.
> However, we wanted to increase interoperability, and we discovered
> that
> Microsoft treats Resource Forks the same way it handles Resource
> forks.
> The first stage was to develop the adouble:ads format, and also change
> vfs_netatalk to vfs_ads. The new functionality now saves the Alternate
> Data Streams in the same directory as the Macintsh Resource forks.
> Moreover, all operations by either Mac or Windows clients (e.g.
> 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
> 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.
> We can share the code of course, it is GPL after all ! But the code
> has
> changed quite much from the vfs_netatalk, and does not compile without
> our changes to samba (which I am not sure you want). However, it is 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 in
> mind, ...
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
Regards,
-Ralph
More information about the samba-technical
mailing list