VFS to NTFS transition

[Ralph Böhme]

Am 28.04.2008 um 18:35 schrieb James Peach:
>> 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?)
>
> These two assumptions are bogus.

Maybe, maybe not. They're defining the engineering focus: limited but  
well defined and and lastly this is vfs_netatalk we're talking about.

> The 10.5 smbfs client does natively propagate Mac metadata and  
> resource forks across SMB. It provides a user experience that is  
> virtually indistinguishable from AFP.


Yeah, I know. And that relies on a server side implementation that  
must store the extra data $somewhere. Later on we can go on enhance  
this and implement a more complete solution probably on basis of  
adouble:sfm and vfs_ads:

Am 24.04.2008 um 15:03 schrieb Shlomi Yaakobovich:
> 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.

So maybe it' time to look at your vfs_ads code and see if it can be  
massaged to build and work in with a generic Samba 3.2? What changes  
have you done to Samba? It should be possible to come up with a  
modified vfs_ads that build within an unpatched Samba 3.2, shouldn't it?
Maybe James is correct after all and I should go this route.

Ralph