VFS to NTFS transition
lists at supported.de
Thu May 1 11:27:57 GMT 2008
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.
More information about the samba-technical