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

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