FreeFileSync Forum

To do this, you'd have to be very comfortable with Linux because you'd have to build FFS from source. The precompiled binaries would not be helpful in your case.

At any rate, there's really no reason to do this. I have QNAP running 4.1.2 and I use External Backup under the Backup Station app. It's ...

I was ripping a CD this morning which causes the sync process to run several times (once as each track file is written to my music folder). The CD had 14 tracks and after 13, FFS opened. Unfortunately, the log output is not real helpful I'm afraid.

This is what the log entry looks like:

3/2/15 9 ...

I'll have to wait for it to happen again. I can get some info on processes from Console but without having a reference point, it's like finding a needle in a haystack.

This will be addressed in the next release:

viewtopic.php?t=1679

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

Is there a way to check? What's mystifying is that it happens so randomly. It happened only once yesterday, despite RTS calling FFS to run over 20 times.

I installed 6.14 a couple of days ago and got everything setup and working. For some unknown reason, about 1 in 5 times RTS successfully calls FFS and FFS completes, it opens the actual FFS application and brings it to the forefront instead of silently terminating.

For example, in 5 hours this ...

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. :)

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?

> 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 ...

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 ...

> 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 ...

> 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 ...

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 ...

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 ...

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 ...

Sorry about that. I've continued on in the other thread.

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 ...

I think the ball is currently on your part, to find out what file or folder is triggering the change:
https://freefilesync.org/forum/viewtopic.php?t=280
That said, I'm not too optimistic to find a root problem, that is solvable by FFS, since all that FFS does is handle the change notification ...

I'll do it again if at some point in the future you'd be willing to look into why it's running FFS every 15-20 seconds only when using AFP.

So far, so good.

I completely formatted the remote drive, wiping out the previous directory structure entirely. I then completely removed FFS from my machine, including the app support directory and preference files.

Regardless of whether I use SMB or AFP, the created and modified dates are both ...

It appears to be working as of right now. Thanks!

Great, so the modtime issue on SMB can be considered solved!

As far as create time goes, I'm working on it. I'll (probably) post a new build later.Zenju

You're the best, truly. Thanks for all of your time and effort.

File modification time and creation time are really separate issues:

1. mod time not copied correctly: => bug, this should never happen (Is this solved now on SMB and the current beta?)
2. create time: => not yet supported by FFS. No bug, but a todo.
1. yep, modified time is now correct on both ...

> Here is the behavior now using AFP for the network protocol

Could you test this with SMB? Since I expect a Samba bug to be the cause of the original issues there probably was never any problem for AFP in any of the beta versions or the releases.

> created time stamp is being reset

I'll see if ...

I just tested it with both SMB and AFP.

A file copy via the Finder preserves both create time and modified time after copying to the NAS.

With FFS, the create time is overwritten in both cases. With AFP, the create time is set to the time when the file is copied. With SMB, the create time is set ...

I had to update the 6.14 beta once to remove the old code setting the modtime that was not needed anymore. Setting the modtime twice shouldn't make any difference, but maybe this is the problem here. So there are two versions of the beta 6.14:

I): = "beta1" behavior + FFS 6.13 setting of modtime ...

FWIW, the behavior of beta 1 and 6.12 are not unique to FFS. If I do a copy from within Finder using SMB, the modified date of the file is preserved but the created date is changed to the modified data.

If I use AFP instead of SMB, both the created and modified timestamps are preserved correctly. I ...

Thanks for your tests! The problems with setting modification times are caused by an old bug in Samba code. Up to FFS 6.12, OS X was sharing the file copy routine with Linux and had a work around implemented for this bug. In 6.13 I've introduced a native file copy algorithm in order to support OS X ...

I also now know why the Sync process is creating files that start with "dot underscore".

All of the main files associated with them have extended attributes (denoted by the @ in -rw-rw-rw-@), namely some form of metadata associated with the file.

I have a feeling this is also related to the recent ...

I wonder if this problem would exist then when using AFP instead of SMB? (Of course, that re-introduces the other issue...)

By the way, I just realized why only certain files are affected. All of the files being sync'd repeatedly were either created or modified after 6.13 was installed and thus sync'd with the wrong timestamps. Files sync'd prior to 6.13 have the correct modified date, so FFS isn't identifying the NAS ...

Nice representation of results, very useful!

> For the sake of comparison, FFS release 6.13 shows the same behavior as Beta 2.

And beta 1 the same as FFS 6.12? Can you confirm? I think the problem with the create date is not new.
Thanks, I try! I am a technologist but my specialty is network and ...

For the sake of comparison, FFS release 6.13 shows the same behavior as Beta 2.

Original file #1:
Created: 1/20/15, 1:44PM
Modified: Today, 8:30AM

On NAS, after sync:
Created: Today, 8:30AM
Modified: Today, 9:53AM

Original file #2:
Created: 1/31/13, 10:17AM
Modified: 12/31/14

On NAS, after sync ...

Beta 2 appears to be setting the created date to the last modified date as well. In addition, it is setting the last modified date to the time the file is copied.

Original file #1:
Created: 1/20/15, 1:44PM
Modified: Today, 8:30AM

On NAS, after sync:
Created: Today, 8:30AM
Modified: Today, 9:49AM ...

With beta 1, the last modified date is carried over. However, the created date is incorrect - it appears to be resetting the created date to the last modified date.

I used two files as tests.

Original file #1:
Created: 1/20/15, 1:44PM
Modified: Today, 8:30AM

On NAS, after sync:
Created: Today, 8 ...

I went ahead and added

*/.*

to my filters to prevent it from trying to sync any of the temp files. That should allow us to focus on the time stamps.

I am installing beta 1 now.

I typed a response, hit "post" and it disappeared. So if you end up with duplicates, I'm sorry. :)

I'm mirroring personal folders on an HFS+ volume (my Mac's local HDD) to a NAS using SMB (RTS with AFP is still broken in 6.13 calling FFS every 20 seconds even though it doesn't identify anything to ...

Subject says it all. Didn't have a problem with 6.12 but 6.13 is repeatedly syncing the same files over and over again. Strangely, it isn't all files.

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.

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 ...

Great app. Congrats.

It's available here (and works great, btw)...

https://freefilesync.org/download.php

FFS 6.12 on OS X 10.10.1 Yosemite does not exhibit this behavior. I can test 6.13 sometime later today.

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.Zenju

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

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

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 ...

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 ...

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 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 ...

Search found 73 matches