Using Mac OS X RealTimeSync with AFP

[htismaqe]

When using RTS to sync with an AFP share, I've noticed that it calls FFS every 20-30 seconds, even if there's no changes to any of the watched folders.

I have confirmed this does not happen with an SMB/CIFS share.

Is this a bug?

[htismaqe]

I'm also seeing the following log messages every time RTS calls FFS to check/sync watched folders:

10/15/14 11:59:32.148 AM    WindowServer[217]    CGXSetWindowListSystemAlpha: Invalid window 204 (index 0/1)


10/15/14 11:59:37.609 AM    FreeFileSync[1508]    mbraHelper Loaded


10/15/14 11:59:38.734 AM    WindowServer[217]    CGXSetWindowListSystemAlpha: Invalid window 206 (index 0/1)


[htismaqe]

Two more messages from the console log:

10/15/14 2:33:19.212 PM FreeFileSync[1320]: *** WARNING: -[NSImage compositeToPoint:operation:] is deprecated in MacOSX 10.8 and later. Please use -[NSImage drawAtPoint:fromRect:operation:fraction:] instead.


10/15/14 2:33:19.213 PM FreeFileSync[1320]: *** WARNING: -[NSImage compositeToPoint:fromRect:operation:] is deprecated in MacOSX 10.8 and later. Please use -[NSImage drawAtPoint:fromRect:operation:fraction:] instead.


Sorry to be posting all this stuff, I don't know if it's valuable or not.

[Zenju]

The warnings are caused by outdated code in the wxWidgets framework and are a reminder for the developers to fix their code. From an end user's point of view they can be ignored, altough it's a nuisance that they are shown, instead of simply fixed.

> calls FFS every 20-30 seconds, even if there's no changes

RTS fills environment variables %change_action% and %change_path% each time it detects a change (see help file chapter "RealtimeSync"). So it should be possible to log these variables and check what file triggered RTS.

[htismaqe]

OK, thanks for the info.

I am working on some NAS stuff today as I had a drive failure in one unit. Once that is done, I want to test the 6.11beta you sent.

I will work on this one after that.

[htismaqe]

I've gotten my NAS issues sorted out but I also am fighting some issues in OS X Yosemite so I've been delayed a little bit. I will get to this one in the next few days.

The good news is that 6.11 beta fixed the other major issue.

[htismaqe]

Any idea how to determine the value of those variables? I've struck out so far trying to figure out how to log or show them...

[htismaqe]

The warnings are caused by outdated code in the wxWidgets framework and are a reminder for the developers to fix their code. From an end user's point of view they can be ignored, altough it's a nuisance that they are shown, instead of simply fixed.

> calls FFS every 20-30 seconds, even if there's no changes

RTS fills environment variables %change_action% and %change_path% each time it detects a change (see help file chapter "RealtimeSync"). So it should be possible to log these variables and check what file triggered RTS.

I still haven't figured this out. The Help file only references Windows. I've figured out how to check the values of all ENV variables but these two appear to be transitive as they aren't currently set.

>RTS fills environment variables %change_action% and %change_path% each time it detects a change (see help file chapter "RealtimeSync"). So it should be possible to log these variables and check what file triggered RTS.

[htismaqe]

Hey, Zenju, if you get a chance could you help me out here? I'm still not able to find the values of the variables you specified. I'm not sure they exist or maybe the syntax is incorrect.

[Zenju]

Environment variables are not specific to FreeFileSync so you can Google for the syntax. On OS X "printenv" will list all variables and values.

[htismaqe]

printenv works, yes. So does just "env".

The problem is that I don't see those variables listed. I'm assuming they're transitive, meaning that they're only set temporarily when they're in use?

I've tried using echo to get those specific variables but that doesn't work either.

Also, generally Linux/OS X variables don't contain % signs, that is more of a Windows convention, so I'm not sure if that is an issue.

[Zenju]

Just tested on OS X:

1. start RTS app from command line
2. put "printenv" into the RTS command window
3. start RTS monitoring

Each time you modify a file in the monitored directories you'll se the file name in variable $changed_file.

[htismaqe]

OK, so my existing command line looks like this in RTS:

"/Applications/FreeFileSync.app/Contents/MacOS/FreeFileSync" "/Users/XXX/Library/Scripts/UserFolders.ffs_batch"


Should I just adjust "printenv" to the front or back of the command?

EDIT: Are you suggesting entering "printenv" into the active terminal window after starting RTS? I did that and I see console messages about starting mbrahelper but I don't get any output for variables.

[htismaqe]

I still haven't been able to get this to work, sorry.

[Zenju]

OK, so my existing command line looks like this in RTS:

"/Applications/FreeFileSync.app/Contents/MacOS/FreeFileSync" "/Users/XXX/Library/Scripts/UserFolders.ffs_batch"


Should I just adjust "printenv" to the front or back of the command?

EDIT: Are you suggesting entering "printenv" into the active terminal window after starting RTS? I did that and I see console messages about starting mbrahelper but I don't get any output for variables.

No, "printenv" is the command entered in RTS. When RTS is started via commandline this will print all environment variables to the console when RTS detects a change - including the two local env vars added by RTS.

[htismaqe]

No, "printenv" is the command entered in RTS. When RTS is started via commandline this will print all environment variables to the console when RTS detects a change - including the two local env vars added by RTS.

How do I enter "printenv" into RTS? Can you maybe post a screenshot?

[htismaqe]

How do I enter "printenv" into RTS? Can you maybe post a screenshot?

I'm still trying to figure this out.

[Zenju]

I'm still trying to figure this out.

I don't know how to explain further: the steps 1 to 3 above should do the trick. If this doesn't work for you, maybe there is some other kind of problem then.

[htismaqe]

I don't know how to explain further: the steps 1 to 3 above should do the trick. If this doesn't work for you, maybe there is some other kind of problem then.

Sorry, your instructions just aren't completely clear to me. I think we're talking past each other.

I'm starting RTS from a shell prompt which I've always referred to as a command line interface, just like CMD in Windows. When you say "enter 'printenv' in the command line", do you mean the terminal window (which stays open after starting RTS manually) or do you mean to enter "printenv" in the command line field of the RTS GUI window?

If it is the latter (and I suspect it is), what is the syntax I need to use? Do I append it to the existing command line? Or do I replace the entire existing command line with "printenv"?

[htismaqe]

I don't know how to explain further: the steps 1 to 3 above should do the trick. If this doesn't work for you, maybe there is some other kind of problem then.

OK, that's odd. I posted a reply and the thread shows that it was updated 6 minutes ago, but my post is nowhere to be found.

At any rate, I think the confusion here is just language. I'm used to referring to a shell prompt as the "command line".

When starting RTS manually, I'm starting it from within Terminal, from a shell prompt. That opens the RTS GUI front end but it also leaves a command line (Terminal) window open until the GUI is terminated.

When you say I should enter "printenv" in the "command line" are you talking about the open shell prompt or are you talking about the command line FIELD in the RTS GUI?

If it's the latter, do I append "printenv" to the existing command line that's already there? Or do I replace the existing command with "printenv"?

[Zenju]

OK, that's odd. I posted a reply and the thread shows that it was updated 6 minutes ago, but my post is nowhere to be found.

At any rate, I think the confusion here is just language. I'm used to referring to a shell prompt as the "command line".

When starting RTS manually, I'm starting it from within Terminal, from a shell prompt. That opens the RTS GUI front end but it also leaves a command line (Terminal) window open until the GUI is terminated.

When you say I should enter "printenv" in the "command line" are you talking about the open shell prompt or are you talking about the command line FIELD in the RTS GUI?

If it's the latter, do I append "printenv" to the existing command line that's already there? Or do I replace the existing command with "printenv"?

Yes it's the latter, just enter printenv as the only command into the RTS window. Then when RTS is running and detects changes, it will execute the printenv command in the console window in the back.

[htismaqe]

SourceForge ate my post again. :)

I got this working this morning and let it run for a few minutes. RTS calls "printenv" ever 20 seconds or so, as expected.

The first time it prints the output to terminal, the variable values are:

change_action=CREATE
change_path=


The second and subsequent times, the variable values are:

change_action=UPDATE
change_path=/Volumes/xxx/Documents


It thinks that there's been a change to the first network share in my watch list. If I connect via SMB, the problem disappears immediately.

Here's a thought as to a possible workaround:

I am mirroring local folders to my NAS. I want local changes to always overwrite remote. I'm not syncing remote changes back to local. Should I remove the network shares from my watch list so that RTS is only watching the local folders? Will that work?

[Zenju]

SourceForge ate my post again. :)

I got this working this morning and let it run for a few minutes. RTS calls "printenv" ever 20 seconds or so, as expected.

The first time it prints the output to terminal, the variable values are:

change_action=CREATE
change_path=


The second and subsequent times, the variable values are:

change_action=UPDATE
change_path=/Volumes/xxx/Documents


It thinks that there's been a change to the first network share in my watch list. If I connect via SMB, the problem disappears immediately.

Here's a thought as to a possible workaround:

I am mirroring local folders to my NAS. I want local changes to always overwrite remote. I'm not syncing remote changes back to local. Should I remove the network shares from my watch list so that RTS is only watching the local folders? Will that work?

You should be able to answer this yourself: If detecting changes on the remote share is not important in your case (or you suffer from spurious change notifications), then yes, deleting the corresponding folder from the watch list is the solution.

[htismaqe]

You should be able to answer this yourself: If detecting changes on the remote share is not important in your case (or you suffer from spurious change notifications), then yes, deleting the corresponding folder from the watch list is the solution.

I didn't know if that would break anything or not. I can certainly delete the network folders from the watch list as a workaround.

Do you think this is something you might fix in a future release or no?

EDIT: Is there any downside to just letting it call FFS every 15-20 seconds? I suppose that's the other workaround is just to ignore the notifications, since they're not technically doing anything and RTS it otherwise doing its job just fine.

[htismaqe]

Just wondering if letting it call FFS that often is going to break something. Does it increase the chances of corruption or other issues?

[Zenju]

Just wondering if letting it call FFS that often is going to break something. Does it increase the chances of corruption or other issues?

Not really. Directory monitoring is supported directly by the OS, which notifies the application about changes, so there is not even strain on the hardware.

[htismaqe]

Not really. Directory monitoring is supported directly by the OS, which notifies the application about changes, so there is not even strain on the hardware.

Cool thanks! If you ever decide to look into it further, let me know. I'll definitely do anything I can to help.

[htismaqe]

I just wanted to check in and let you know that the problem is (mysteriously) gone.

I got a new 3TB drive for Christmas and instead of upgrading my NAS, I decided to pull the 1TB drive and configure it from scratch. After doing so, I no longer get constant calls to FFS from RTS when connected to my shares via AFP.

[htismaqe]

We left for a mini-vacation and I shut my iMac down while we were gone. Upon powering it up today, the problem returned. Still no clue what is causing it.

[htismaqe]

Continued from the other thread...

I've already gathered the output from the variables you outlined in one of my posts above.

RTS thinks the folders on my share have changed and triggers FFS. FFS then reports back that nothing has changed.

If there's additional troubleshooting I can do, I'm all for it. I'm just not sure where to go next.

[htismaqe]

First off, I apologize for being such a pain. Hopefully, I have figured something out. If you can just validate my assumptions here, I think I may have a permanent workaround.

I was hesitant to just remove the remote folders from RTS monitoring for fear of losing data but then it dawned on my that RTS doesn't actually SYNC anything, all it does it monitor folders and call FFS when necessary.

I have created an FFS batch file that mirrors 5 local folders to the same 5 folders on a remote NAS. By default, if I drag that batch file into RTS, RTS is automatically setup to monitor BOTH sets of folders (10 in all, 5 local, 5 remote).

In normal operation, RTS would monitor both local and remote folders and call FFS to compare and mirror (local to remote) if any of them changed. If for example I accidentally deleted a file on the remote NAS, RTS would immediately call FFS and put the file back because it still exists locally.

My fear was that if I remove the remote folders from monitoring, RTS would only call FFS when changes were made local and FFS would only mirror changes made to local directories. In the above example, I was worried the accidentally deleted file would disappear forever. However, I believe that assumption is incorrect.

If I remove those folders from RTS, RTS would only call FFS when changes are made to the local folders. However, if I had made changes to the remote folders (such as the accidental deletion of a file in the example above), those changes would be immediately mirrored the next time FFS is called.

Going back to my example, if I accidentally deleted a remote file, RTS would not see it and do nothing. However, the next time I change a local file, RTS will call FFS. FFS will do a compare and see that the accidentally deleted file is missing and put it back.

Is all of this thinking correct? If so, I will consider this issue closed.

[htismaqe]

I was able to validate this myself. Here are my results.

I removed the remote folders from RTS. I let it sit for 30 minutes and verified that it did not call FFS even one time.

1. On the local drive, I created folder1 and folder2, each containing file1 and file2, and allowed RTS to call FFS, mirroring them to the NAS drive.
2. I deleted folder 2/file2 and waited. As expected, RTS did not run.
3. I added folder 1/file3 and allowed it to sync. After the sync, folder2/file2 was restored.

I'm not sure how exhaustive this test was but I think it's sufficient at this point.

EDIT: The only downside of this approach is the potential for long periods of time to pass between local changes. For myself, this is remedied by the fact that when I sleep/wake the Mac, the NAS volume is disconnected/reconnected. This causes RTS to immediately trigger a compare/sync, so I'm guaranteeing that my files get synced every morning when I wake up the machine.

[htismaqe]

Of course, it turned out to be too good to be true.

If I remove all of the remote folders, RTS stops checking for the remote Volume altogether. So if the NAS goes offline, RTS stays active. If a local change is made, it tries to sync which of course fails. Not only that but it creates a new volume with the same name as the original destination volume. So when the NAS comes back online, it now has to mount itself with a different path because its original path already exists.

Of course, as soon as a I add a single remote folder back to RTS, it starts trying to sync every 20 seconds again.

[Zenju]

Continued from the other thread...

I've already gathered the output from the variables you outlined in one of my posts above.

RTS thinks the folders on my share have changed and triggers FFS. FFS then reports back that nothing has changed.

If there's additional troubleshooting I can do, I'm all for it. I'm just not sure where to go next.

Okay, this was your result:

> change_action=UPDATE
> change_path=/Volumes/xxx/Documents

[Zenju]

First off, I apologize for being such a pain. Hopefully, I have figured something out. If you can just validate my assumptions here, I think I may have a permanent workaround.

I was hesitant to just remove the remote folders from RTS monitoring for fear of losing data but then it dawned on my that RTS doesn't actually SYNC anything, all it does it monitor folders and call FFS when necessary.

I have created an FFS batch file that mirrors 5 local folders to the same 5 folders on a remote NAS. By default, if I drag that batch file into RTS, RTS is automatically setup to monitor BOTH sets of folders (10 in all, 5 local, 5 remote).

In normal operation, RTS would monitor both local and remote folders and call FFS to compare and mirror (local to remote) if any of them changed. If for example I accidentally deleted a file on the remote NAS, RTS would immediately call FFS and put the file back because it still exists locally.

My fear was that if I remove the remote folders from monitoring, RTS would only call FFS when changes were made local and FFS would only mirror changes made to local directories. In the above example, I was worried the accidentally deleted file would disappear forever. However, I believe that assumption is incorrect.

If I remove those folders from RTS, RTS would only call FFS when changes are made to the local folders. However, if I had made changes to the remote folders (such as the accidental deletion of a file in the example above), those changes would be immediately mirrored the next time FFS is called.

Going back to my example, if I accidentally deleted a remote file, RTS would not see it and do nothing. However, the next time I change a local file, RTS will call FFS. FFS will do a compare and see that the accidentally deleted file is missing and put it back.

Is all of this thinking correct? If so, I will consider this issue closed.

Yes your assumptions are correct. RTS is only used for detecting changes, FFS on the other hand will always sync irrespective of what RTS detected.

[Zenju]

> So if the NAS goes offline, RTS stays active.

Usually RTS should go inactive, but it makes sense, since you don't monitor the NAS anymore in your new setup.

> If a local change is made, it tries to sync which of course fails. Not only that but it creates a new volume

That's bad. On Windows if a network drive is not existing FFS will fail and cannot create it. On Linux/Mac network drives are mounted to a local folder name. But why is this a problem? If a network share is mounted to an already existing local folder, it should just temporarily replace it, shouldn't it? In other words, the NAS should still be able to mount under the same local folder despite it already existing?

[Zenju]

Okay let's try something. I've created a test version of RealtimeSync that prints out all the information it has to the console. This should help to find out what kind of notification "/Volumes/xxx/Documents" is receiving every 20 seconds:

1. Start the following version of RTS from console:
[404, Invalid URL: https://freefilesync.org/RealtimeSync_6.14_beta_Mac_OS_X_64-bit.zip]

2. Setup RTS with your "/Volumes/xxx/Documents" folder on the NAS that keeps triggering every 20 seconds, just as you did in your earlier tests. It doesn't matter what you enter as "command" in RTS.

3. Wait some time after you see a few entries in the console and let me know what it printed.

[htismaqe]

> So if the NAS goes offline, RTS stays active.

Usually RTS should go inactive, but it makes sense, since you don't monitor the NAS anymore in your new setup.

> If a local change is made, it tries to sync which of course fails. Not only that but it creates a new volume

That's bad. On Windows if a network drive is not existing FFS will fail and cannot create it. On Linux/Mac network drives are mounted to a local folder name. But why is this a problem? If a network share is mounted to an already existing local folder, it should just temporarily replace it, shouldn't it? In other words, the NAS should still be able to mount under the same local folder despite it already existing?

SF eats my first post and doubles my 2nd... :)

[htismaqe]

> So if the NAS goes offline, RTS stays active.

Usually RTS should go inactive, but it makes sense, since you don't monitor the NAS anymore in your new setup.

> If a local change is made, it tries to sync which of course fails. Not only that but it creates a new volume

That's bad. On Windows if a network drive is not existing FFS will fail and cannot create it. On Linux/Mac network drives are mounted to a local folder name. But why is this a problem? If a network share is mounted to an already existing local folder, it should just temporarily replace it, shouldn't it? In other words, the NAS should still be able to mount under the same local folder despite it already existing?

I really wish I could figure why sometimes SourceForge decides to re-prompt me for username and password instead of posting my reply. It takes a lot of time to re-type everything... :)

> If a network share is mounted to an already existing local folder, it should just temporarily replace it, shouldn't it? In other words, the NAS should still be able to mount under the same local folder despite it already existing?

Unfortunately, no. If a folder already exists in /Volumes, OS X mounts the new volume as folder-1. For example, if I mount xxx via AFP, it creates /Volumes/xxx. If I then mount xxx via SMB, it creates /Volumes/xxx-1.

In the case of RTS/FFS, this is doubly bad. If the drive is unavailable, the call to /Volumes/xxx by FFS causes the creation of /Volumes/xxx. When the drive reconnects, the network share is now available via /Volumes/xxx-1, which of course completely breaks FFS because it's looking in the wrong path.

I've created a temporary workaround for now. I've mapped xxx via AFP and then created a dummy share call "SMB" and mapped it via SMB. I have RTS monitoring SMB but FFS is setup to sync xxx. Now if the NAS goes offline, my Mac goes to sleep, or I otherwise lose my network connection, BOTH drives are unmounted and RTS goes into suspend mode until they come back online. Since AFP connects much faster than SMB, there won't be many (if any) instances where xxx is available but SMB isn't so that should work for now.

I'm super busy with some other stuff but will begin testing the new beta you just posted as soon as I possibly can. Thanks again for all of your help!

[Zenju]

I really wish I could figure why sometimes SourceForge decides to re-prompt me for username and password instead of posting my reply. It takes a lot of time to re-type everything... :)

> If a network share is mounted to an already existing local folder, it should just temporarily replace it, shouldn't it? In other words, the NAS should still be able to mount under the same local folder despite it already existing?

Unfortunately, no. If a folder already exists in /Volumes, OS X mounts the new volume as folder-1. For example, if I mount xxx via AFP, it creates /Volumes/xxx. If I then mount xxx via SMB, it creates /Volumes/xxx-1.

In the case of RTS/FFS, this is doubly bad. If the drive is unavailable, the call to /Volumes/xxx by FFS causes the creation of /Volumes/xxx. When the drive reconnects, the network share is now available via /Volumes/xxx-1, which of course completely breaks FFS because it's looking in the wrong path.

I've created a temporary workaround for now. I've mapped xxx via AFP and then created a dummy share call "SMB" and mapped it via SMB. I have RTS monitoring SMB but FFS is setup to sync xxx. Now if the NAS goes offline, my Mac goes to sleep, or I otherwise lose my network connection, BOTH drives are unmounted and RTS goes into suspend mode until they come back online. Since AFP connects much faster than SMB, there won't be many (if any) instances where xxx is available but SMB isn't so that should work for now.

I'm super busy with some other stuff but will begin testing the new beta you just posted as soon as I possibly can. Thanks again for all of your help!

> I really wish I could figure why sometimes SourceForge decides to re-prompt me for username and password instead of posting my reply. It takes a lot of time to re-type everything... :)

Oh yeah, this is a PITA for as long as I can remember. Not preserving the message text (when the cookie is outdated?) is Sourceforge's biggest (design-)bug IMHO.

I've created a bug tracker item on Sourceforge. Feel free to add your expierence thereby raising the priority:
https://sourceforge.net/p/forge/site-support/9579/

> Unfortunately, no. If a folder already exists in /Volumes, OS X mounts the new volume as folder-1.

Okay, I guess it depends on how you mount, then. I tested on OS X by mounting manually via command line and specifying a target folder for "mount" and it didn't matter that this folder existed and/or was not empty.

> In the case of RTS/FFS, this is doubly bad

So the best solution would then be to fix-up RTS. Looking forward to the new logs.

[htismaqe]

Here's the output. I setup RTS to only monitor one remote directory. If I setup more than one, it lists all of them. It doesn't look particularly verbose to me but hopefully you'll know what those hex offsets are...

xxx-IMAC:MacOS xxx$ ./RealtimeSync
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:53:36.857 FreeFileSync[2081:49716] mbraHelper Loaded
2015-01-29 12:53:50.738 RealtimeSync[2079:49122] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:54:06.820 FreeFileSync[2084:50485] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:54:36.798 FreeFileSync[2088:51241] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:55:06.761 FreeFileSync[2090:52004] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:55:36.804 FreeFileSync[2092:52762] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:56:06.783 FreeFileSync[2094:53487] mbraHelper Loaded


[htismaqe]

> I really wish I could figure why sometimes SourceForge decides to re-prompt me for username and password instead of posting my reply. It takes a lot of time to re-type everything... :)

Oh yeah, this is a PITA for as long as I can remember. Not preserving the message text (when the cookie is outdated?) is Sourceforge's biggest (design-)bug IMHO.

I've created a bug tracker item on Sourceforge. Feel free to add your expierence thereby raising the priority:
https://sourceforge.net/p/forge/site-support/9579/

> Unfortunately, no. If a folder already exists in /Volumes, OS X mounts the new volume as folder-1.

Okay, I guess it depends on how you mount, then. I tested on OS X by mounting manually via command line and specifying a target folder for "mount" and it didn't matter that this folder existed and/or was not empty.

> In the case of RTS/FFS, this is doubly bad

So the best solution would then be to fix-up RTS. Looking forward to the new logs.

> Okay, I guess it depends on how you mount, then. I tested on OS X by mounting manually via command line and specifying a target folder for "mount" and it didn't matter that this folder existed and/or was not empty.

I normally mount directly from Finder using Automator. The command line works ok for SMB but has a myriad of other issues. Certainly, you can prevent OS X from auto-creating volume names by forcing it to mount to a specific folder but I have yet to get it to work that smoothly. All of my auto-mount routines are done via the GUI for that reason.

[Zenju]

Here's the output. I setup RTS to only monitor one remote directory. If I setup more than one, it lists all of them. It doesn't look particularly verbose to me but hopefully you'll know what those hex offsets are...

xxx-IMAC:MacOS xxx$ ./RealtimeSync
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:53:36.857 FreeFileSync[2081:49716] mbraHelper Loaded
2015-01-29 12:53:50.738 RealtimeSync[2079:49122] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:54:06.820 FreeFileSync[2084:50485] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:54:36.798 FreeFileSync[2088:51241] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:55:06.761 FreeFileSync[2090:52004] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:55:36.804 FreeFileSync[2092:52762] mbraHelper Loaded
0x00020401    /Volumes/xxx/Documents
2015-01-29 12:56:06.783 FreeFileSync[2094:53487] mbraHelper Loaded


Thanks! Unfortunately the log results are not conclusive: Hex code "0x00020401" stands for

kFSEventStreamEventFlagItemIsDir |
kFSEventStreamEventFlagMustScanSubDirs |
kFSEventStreamEventFlagItemInodeMetaMod

I cannot find any documentation on what "kFSEventStreamEventFlagItemInodeMetaMod" means and "kFSEventStreamEventFlagMustScanSubDirs" is documented as follows:

Your application must rescan not just
the directory given in the event, but all its children,
recursively. This can happen if there was a problem
whereby events were coalesced hierarchically. For
example, an event in /Users/jsmith/Music and an
event in /Users/jsmith/Pictures might be coalesced
into an event with this flag set and path=/Users/jsmith.
If this flag is set you may be able to get an
idea of whether the bottleneck happened in the
kernel (less likely) or in your client (more
likely) by checking for the presence of the
informational flags kFSEventStreamEventFlagUserDropped or
kFSEventStreamEventFlagKernelDropped.

I had hoped to see an event type that is nonsensical and can generally be ignored, but this is probably not the case with "kFSEventStreamEventFlagMustScanSubDirs".

[htismaqe]

I think for right now, I'll just continue to use my workaround with the dummy SMB share. If you think of anything else I can try, let me know. When do you think 6.14 will be released?

[Zenju]

I think for right now, I'll just continue to use my workaround with the dummy SMB share. If you think of anything else I can try, let me know. When do you think 6.14 will be released?

Probably in about a week or two.

[htismaqe]

Great. For right now, I'm just going to chill and wait for 6.14 release. I've got about 15 versions on my machine right now. :)