In reply to this post by Ralph Böhme

On Jun 18, 2013, at 9:40 AM, Ralph Böhme <



> Hi George,

>

> Am 18.06.2013 um 17:49 schrieb George K Colley <

>

>> On Jun 18, 2013, at 7:30 AM, Ralph Böhme <

>>

>>> Hi everybody,

>>>

>>> Apple is moving to SMB2 as the default filesharing protocol in it's next OS X incarnation 10.9 Maverick:

>>> <

>>>

>>> Network traces reveal interesting stuff:

>>> * is searching remote SMB2 volumes supported (aka Spotlight) ? Hint: the AFP network command is called FPSpotlight*RPC*

>> Mac to Mac SMB has support Spotlight since OS X 10.7, there is nothing new here.

>

> ah, I missed that being busy reverse engineering and implementing Spotlight w AFP/Netatalk.

>

>>> * in which format is OS X specific stuff (FinderInfo, Ressource Fork) sent across the wire ?

>> We have always supported FinderInfo and Resource forks using the Named Streams or with dot underbar files, depending in the server support.

>

> I know, but I imagine things may break at subtle points, e.g. some applications and file formats still use resource forks larger then what fits into an extended attribute (vfs objectt streams_xattr). I'm also looking into compatibility issues on volumes that have been accessed or are accessed in parallel with Netatalk/AFP.

> > Hi George,> Am 18.06.2013 um 17:49 schrieb George K Colley < [hidden email] >:>> On Jun 18, 2013, at 7:30 AM, Ralph Böhme < [hidden email] > wrote:>>>>> Hi everybody,>>>>>> Apple is moving to SMB2 as the default filesharing protocol in it's next OS X incarnation 10.9 Maverick:>>> < http://www.afp548.com/2013/06/11/smb2-and-you-saying-goodbye-to-afp-in-os-x-mavericks/ >>>>>> Network traces reveal interesting stuff:>>> * is searching remote SMB2 volumes supported (aka Spotlight) ? Hint: the AFP network command is called FPSpotlight*RPC*>> Mac to Mac SMB has support Spotlight since OS X 10.7, there is nothing new here.> ah, I missed that being busy reverse engineering and implementing Spotlight w AFP/Netatalk.>>> * in which format is OS X specific stuff (FinderInfo, Ressource Fork) sent across the wire ?>> We have always supported FinderInfo and Resource forks using the Named Streams or with dot underbar files, depending in the server support.> I know, but I imagine things may break at subtle points, e.g. some applications and file formats still use resource forks larger then what fits into an extended attribute (vfs objectt streams_xattr). I'm also looking into compatibility issues on volumes that have been accessed or are accessed in parallel with Netatalk/AFP.



If the remote server supports NTFS Name Streams then that should not be an issue, since NTFS Name Streams support the same size as a file.

If the remote server doesn't support Name Streams then this data is stored in the famous and ugly dot underbar file. Which is handle by OS X.



So I am not sure why this should be an issue. If NTFS Name Streams is support then SMB handles resource forks the same as AFP from the client side.



George

> -Ralph

>

> --

> Ralph Böhme <

> Netatalk Developer | Support | Services

> Curslacker Deich 254, 21039 Hamburg, Germany

> Phone: +49-(0)40-20235977

> http://www.netafp.com/



On Jun 18, 2013, at 9:40 AM, Ralph Böhme < [hidden email] > wrote:If the remote server supports NTFS Name Streams then that should not be an issue, since NTFS Name Streams support the same size as a file.If the remote server doesn't support Name Streams then this data is stored in the famous and ugly dot underbar file. Which is handle by OS X.So I am not sure why this should be an issue. If NTFS Name Streams is support then SMB handles resource forks the same as AFP from the client side.George> -Ralph> --> Ralph Böhme < [hidden email] > Netatalk Developer | Support | Services> Curslacker Deich 254, 21039 Hamburg, Germany> Phone: +49-(0)40-20235977