Re: Mounted cifs share and repeat=watch bidirectional sync

Since 2.53.1 it is possible to set the repeat preference to both watch
filesystem changes and do a periodical sync. The syntax is repeat =
watch+<seconds>. For example, repeat = watch+3600, which does a sync every
hour in addition to constantly watching for changes.

You haven't mentioned the system you're on, so I'm going to assume Linux,
which uses inotify to watch for filesystem changes. You can try an external
utility like inotifywatch or inotifywait to see if changes on the other
root are detected or not. A very quick and shallow search shows that
inotify does not work on cifs.

On Thu, 9 Jan 2025 at 09:23, Laurent Guerard <[email protected]> wrote:

>
> Sorry for the revive of this, but I'm still having the same issue using
> 2.53.5. Local changes triggers remote update, but not the other way around.
> Which weirdly enough works when I start the GUI.
> It seems that the trigger doesn't work from mounted share somehow, any
> ideas why ?
> On Monday, May 9, 2022 at 2:39:21 PM UTC+2 Peter Ardo wrote:
>
>> Thanks for reply, yes, I agree, the question also can be translated as "
>> Can two unison processes run at the same time and function correctly
>> in terms of locking/mutual exclusion?"
>> I can live with just hourly synchronization as well (the remote NAS only
>> serves as backup solution for the case there is no Internet at my
>> customer's office), but I think (am I right?) that the hourly sync would
>> run faster if at least in the VPS-> NAS direction the repeat=watch real
>> time sync would happen.
>>
>>
>> Greg Troxel a következőt írta (2022. május 9., hétfő, 13:59:51 UTC+2):
>>
>>>
>>> Peter Ardo <[email protected]> writes:
>>>
>>> > When syncing root1=/var/samba/share with root2=/mnt/share (where
>>> /mnt/share
>>> > is a mounted cifs share) with option repeat=watch only the root1
>>> changes
>>> > trigger a synchronization. It is probably because root2 being a
>>> mounted
>>> > share.
>>> > Can I somehow combine watch sync with periodical sync?
>>>
>>> I don't know, but behind your question lurks a different question that I
>>> find interesting:
>>>
>>> Can two unison proceses run at the saem time and function correctly
>>> in terms of locking/mutual exclusion? If so, how is the locking
>>> done, and are locks released during quiescent periods of a
>>> repeat=watch invocation?
>>>
>>> I would say that one should be able to answer this question from the
>>> manual, and if not a clarification is in order, being careful to
>>> separate what is spec and what happens to be true in the present
>>> implementation.
>>>
>>> And I would look favorably on addressing locking, if it's not there, as
>>> a basic correctness issue. However, it would need to be portable,
>>> relying on only what POSIX requires, perhasp with some accomodation for
>>> Windows.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
>

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].