External Sync VFS module

[Alex Austin]

Only open, sync, close, rename, mkdir, and unlink.

Also, I considered making sync, close, rename, and mkdir synchronous,
waiting for unison to return, but I decided that might be too heavy handed
for now.
On Apr 27, 2016 9:00 PM, "Ira Cooper" <ira at wakeful.net> wrote:

> So it spins up a thread per VFS op?
>
> Just so I understand correctly? :)
>
> -Ira
>
> On Wed, Apr 27, 2016 at 9:18 PM, Alex Austin <aaustin at nevelex.com> wrote:
>
>> The daemon is not single threaded - it uses the threading mixin on socket
>> to start a new thread on every connection. Given the local nature of the
>> socket I would expect minimal overhead on socket creation and connection.
>> Also, the protocol as I defined it applies meaning to an end of file
>> condition.
>> On Apr 27, 2016 7:46 PM, "Ira Cooper" <ira at wakeful.net> wrote:
>>
>>> Please, can we allocate a small amount of memory and not have this
>>> connect and disconnect constantly... It just looks ugly.
>>>
>>> Also do we need a license at the top of the python daemon?
>>>
>>> Is the fact that this daemon is single threaded going to cause a problem?
>>>
>>> Just some thoughts looking at it,
>>>
>>> -Ira
>>>
>>> On Wed, Apr 27, 2016 at 8:04 PM, Jeremy Allison <jra at samba.org> wrote:
>>>
>>>> On Tue, Apr 26, 2016 at 04:51:51PM -0500, Alex Austin wrote:
>>>> > Hello,
>>>> > I've written a Samba VFS module to run an external file-sync program,
>>>> and
>>>> > would appreciate feedback.
>>>>
>>>> Currently you call the SMB_VFS_NEXT_XXX() function,
>>>> but then always call the sendsyncmsg() without
>>>> regard to whether the VFS call succeeded or failed.
>>>>
>>>> Don't you need to check the return first, and only
>>>> call sendsyncmsg() on success ?
>>>>
>>>> Jeremy.
>>>>
>>>>
>>>
>