[PATCH] Re: fruit_rename() prepend ._ again if fruit:ressource=file

Jones Syue jonessyue at qnap.com
Tue Jun 27 10:11:03 UTC 2017


Hellp Ralph,

Thank you for kindly feedback!

1. How about  fruit:resource=stream?

Yes as you mentioned the reason is design for netatalk (afp)
compatibility, hence so far fruit:resource=file is preferred.

2. Why rename with prefix string "._" from Windows client?

Some (power?) users might want to manually handle the
AppleDouble files from Windows clients,
because macOS Finder is not allowed do this:
rename a file with prefix string "._" or prefix char "." (single dot).
But im not quite sure the scenario or objective so far,
will ask for more details and come back to list soon.

With earlier version if "vfs objects = fruit" is not set,
they could rename files with prefix string "._" from an Windows client.
But now if "vfs objects = fruit" is set,
they might a bit confuse because finally the destination name
with prefix string "._._" is not as expected prefix "._",
hence might consider to keep this special rename case with vfs_fruit.



--
Regards,
Jones Syue | 薛懷宗
QNAP Systems, Inc.

On Tue, Jun 27, 2017 at 4:46 PM, Ralph Böhme <slow at samba.org> wrote:

> On Tue, Jun 27, 2017 at 03:02:14PM +0800, Jones Syue via samba-technical
> wrote:
> > Hello list,
> >
> > Test master (4.7.0pre1-GIT-bcfa12c) also has this symptom,
> > refer to attach gdb log,
> > 1st rename() and 2nd rename() are came from fruit_rename(),
> > which call SMB_VFS_NEXT_RENAME() twice.
> >
> > Attached patch could address this issue,
> > this patch checks if the source appledouble basname matched
> > the destination basename; if they are matched,
> > would goto done and avoid 2nd rename().
> > Please help review and any suggestions are appreciated,
> > thank you.
> >
> > For example,
> > a text file called "newfile.txt",
> > and win8.1 windows explorer renamed it to "._newfile.txt".
> > In fruit_rename(),
> > 1. The 1st SMB_VFS_NEXT_RENAME() do rename:
> >    ./newfile.txt -> ./_.newfile.txt
> > 2. Then this patch check and found that the source appbledouble
> >    basename (._newfile.txt) matched the destination basename
> >    (._newfile.txt), would goto done.
> >    Hence the 2nd SMB_VFS_NEXT_RENAME() is not called.
> >
> > Here is the smb.conf
> > [global]
> > fruit:nfs_aces = no
> > fruit:veto_appledouble = no
> > vfs objects =  shadow_copy2 catia fruit streams_depot aio_pthread
>
> fwiw, unless you need Netatalk compatibility, as you're using
> streams_depot for
> the streams and not streams_xattr, you could enable fruit:resource=stream.
> That
> would also fix the rename issue.
>
> Cheerio!
> -slow
>


More information about the samba-technical mailing list