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.