samba - Apr 2016 - Migration to vfs_fruit with existing AppleDouble files?

Thanks for the response!

This would be really helpful because we use a lot of old adobe type 1 fonts
that are 100% resource fork and are rendered unusable without the
marshalled xattr's in addition to the AFP_ streams.

While ideally having it seamlessly integrated into samba would be great, if
it's easier to run a one-time conversion utility we can do that too.

Thanks!
-S

On Wed, Apr 27, 2016 at 12:32 AM, Ralph Boehme <slow at samba.org> wrote:
> On Fri, Apr 22, 2016 at 03:18:31PM -0700, Scott Call wrote:
> > Hello!
> >
> > I have a quite large installation that currently supports OSX clients
by
> > forcing them to SMB1 with no streams (via the "nsmb.conf")
file.
> >
> > This setup forces the OSX clients to generate their own ._[FILENAME]
> > appledouble files for files with resource forks (like adobe
documents).
> >
> > We recently discovered the fine work that's been done on vfs_fruit
and
> > wanted to see it it could help us.
> >
> > We have setup a test bed with a newer version of samba and vfs_fruit
> > implemented and the behavior seems much better (faster, easier, etc)
we
> > just have one issue we've found.
> >
> > The OSX generated AppleDouble files are not compatible with the
vfs_fruit
> > generated ones.
>
> Compatible, but containing a different metadata subset. OS X generated
> AppleDouble contain marshalled xattr, Samba's don't.
>
> > I think the difference (or at least part of it) is the files made by
OSX
> > might have all streams in them not just the AFP_* streams and the
files
> > themselves don't have xattr's set.
>
> Yes.
>
> > Ideally we would like to upgrade our existing server to a newer
version
> > using vfs_fruit and letting the VFS handle the AppleDouble files.
>
> vfs_fruit converts the AppleDouble files on access, the AppleDouble
> marshalled xattrs are discareded however. It's not rocket science to
> add code for migrating the xattr data, but it will probably take a few
> days of tedious work.
>
> Cheerio!
> -slow
>

Am 27.04.2016 um 19:08 schrieb Scott Call:
> Thanks for the response!
>
> This would be really helpful because we use a lot of old adobe type 1 fonts
> that are 100% resource fork and are rendered unusable without the
> marshalled xattr's in addition to the AFP_ streams.
>
> While ideally having it seamlessly integrated into samba would be great, if
> it's easier to run a one-time conversion utility we can do that too.
[volume_default_settings]
  appledouble = ea
  ea = samba

and there is a similar problem with netatalk - "appledouble = ea" is 
only for new files and a recently added option - no idea how to switch 
from netatalk to samba in a sane way when you have thousands of adobe 
type 1 fonts on your shares :-(
> On Wed, Apr 27, 2016 at 12:32 AM, Ralph Boehme <slow at samba.org>
wrote:
>
>> On Fri, Apr 22, 2016 at 03:18:31PM -0700, Scott Call wrote:
>>> Hello!
>>>
>>> I have a quite large installation that currently supports OSX
clients by
>>> forcing them to SMB1 with no streams (via the
"nsmb.conf") file.
>>>
>>> This setup forces the OSX clients to generate their own
._[FILENAME]
>>> appledouble files for files with resource forks (like adobe
documents).
>>>
>>> We recently discovered the fine work that's been done on
vfs_fruit and
>>> wanted to see it it could help us.
>>>
>>> We have setup a test bed with a newer version of samba and
vfs_fruit
>>> implemented and the behavior seems much better (faster, easier,
etc) we
>>> just have one issue we've found.
>>>
>>> The OSX generated AppleDouble files are not compatible with the
vfs_fruit
>>> generated ones.
>>
>> Compatible, but containing a different metadata subset. OS X generated
>> AppleDouble contain marshalled xattr, Samba's don't.
>>
>>> I think the difference (or at least part of it) is the files made
by OSX
>>> might have all streams in them not just the AFP_* streams and the
files
>>> themselves don't have xattr's set.
>>
>> Yes.
>>
>>> Ideally we would like to upgrade our existing server to a newer
version
>>> using vfs_fruit and letting the VFS handle the AppleDouble files.
>>
>> vfs_fruit converts the AppleDouble files on access, the AppleDouble
>> marshalled xattrs are discareded however. It's not rocket science
to
>> add code for migrating the xattr data, but it will probably take a few
>> days of tedious work
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20160427/91cbaed7/signature.sig>

On Wed, Apr 27, 2016 at 10:08:46AM -0700, Scott Call
wrote:
> Thanks for the response!
> 
> This would be really helpful because we use a lot of old adobe type 1 fonts
> that are 100% resource fork and are rendered unusable without the
> marshalled xattr's in addition to the AFP_ streams.
resource forks are not xattrs and *are* converted. :)

Cheerio!
-slow

Am 27.04.2016 um 19:29 schrieb Ralph Boehme:
> On Wed, Apr 27, 2016 at 10:08:46AM -0700, Scott Call wrote:
>> Thanks for the response!
>>
>> This would be really helpful because we use a lot of old adobe type 1
fonts
>> that are 100% resource fork and are rendered unusable without the
>> marshalled xattr's in addition to the AFP_ streams.
>
> resource forks are not xattrs and *are* converted. :)
but what does that all mean in context "appledouble = ea"?

or ask it the other way round: is there a way to get rid of all 
"extended attributes" on a netatalk share (recursive) without damage 
real data?

[volume_default_settings]
  appledouble = ea
  ea = samba


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20160427/43c12755/signature.sig>

(apologies to Ralph, I replied directly to him w/o copying the lists, so
here we go again)


In my testing that wasn't the case.  If I manually copy the apple generated
AppleDouble file and it's 0 byte main file to my test system,  the correct
size (including the resource forks) are shown but the file type is not
translated.

Using "GetFileInfo" a file copied to the new (vfs_fruit) server using
finder will show:
type: "tfil"
creator: "movr"

but the same file with the AppleDouble copied at the unix level (scp)  from
the old server shows:
type: "\0\0\0\0"
creator: "\0\0\0\0"

So I think the missing piece is com.apple.FinderInfo xattr?

Thanks!

On Wed, Apr 27, 2016 at 10:29 AM, Ralph Boehme <slow at samba.org> wrote:
> On Wed, Apr 27, 2016 at 10:08:46AM -0700, Scott Call wrote:
> > Thanks for the response!
> >
> > This would be really helpful because we use a lot of old adobe type 1
> fonts
> > that are 100% resource fork and are rendered unusable without the
> > marshalled xattr's in addition to the AFP_ streams.
>
> resource forks are not xattrs and *are* converted. :)
>
> Cheerio!
> -slow
>