FreeFileSync Forum

For the record: a workaround for this issue is to disable the TimeBroker service via the registry (sevices.msc GUI does not allow to set this service to disabled).

The ony free tool that I have good experience with is Testdisk + PhotoRec from CGsecurity.

Does anyone who uses Windows 10 experience high CPU usage of the process RunTimeBroker during and even after syncing using FreeFileSync? In my case, I observe three scenarios:

1) RunTimeBroker high CPU/MEM usage during sync but drops as soon as the sync is done
2) RunTimeBroker high CPU/MEM usage ...

If you're still on Windows XP I can understand your request since the GUI feedback for file operations is very limited on XP. You might want to take a look at this program: teracopy

Afaik, this is not possible. The only switch for controlling the last logfile is in globalsettings.xml and is about controlling its max filesize.

I don't know this cloud service, but could it be some synchronization software process (like Dropbox) is running in the background and keeps a lock on this folder?

Can you copy files manually with a windows explorer instance running with highest privileges (as administrator) to your FTP?

It does. Unless you've set the batch job option to show the process dialog or set the error handling to popup.

You probably mounted your share read-only. Remount in rw mode, apply permissions using chmod then remount normally.

Hm. You could of course create a new scheduled task that runs a batch script that kills the process FreeFileSync_x64.exe if it's running, and schedule that task to be executed 2 hours after the start of the FFS batch job.

That will kill all instances of FreeFileSync_x64.exe however, and you've ...

a) You could not use a batch script to start the FFS batch job. Just call the freefilesync.exe directly and pass the path to the .ffs_batch as an argument. Then the task scheduler option will work correctly.

b) Handle the desired timeout in a script using a counter. Windows batch scripting does not ...

Yes I'd use the Windows task scheduler for this. The settings tab of a task has the option to stop a task if it's running for longer than <n> hours/days:

[404, Invalid URL: http://image.bayimg.com/30daba79b3c0dad1f6aa31329b415f1a20b794e7.jpg]

Update: correction, this won't work. It would kill the ...

It depends on how you start your FFS batch jobs. If you use a Windows batch file, you could store the PID of each new instance you start like this:

http://stackoverflow.com/questions/9486960/windows-batch-scripting-get-pid-of-just-started-process

But again, what is the underlying question here ...

Finally found the root cause of my issue. As stated earlier, it has nothing to do with waking NAS drives from hibernation. I created an AutoIt script that accessed the target drive on my NAS in every possible way it supports, then checked the drive status and if this would return 'ready' it would ...

1) What you call a 'sub job' (folder pair) isn't spawned as a separate process. A FFS job runs as a single process which then processes the folder pairs. So no.

2) Yes, you can use taskkill /PID <ID> for this.

Out of curiosity, what are you trying to accomplish? Because taskkill can kill processes ...

You need to mount the smb share first: http://cri.ch/linux/docs/sk0001.html

The 'select view' icons on the bottom are only for controlling what is shown on the grid. They do not influence the actual sync action.

In your case, I would not choose two-way sync but update (mirror source to destination) WITH versioning enabled. This will create a nice 1 on 1 backup of your ...

So your .bat is executing OK but you simply do not want to see the CMD window right? There are several ways:

1) If you have scheduled the .bat file to be executed via Windows Task Scheduler, you can hide the CMD window by specifying a different Windows account for the task (SYSTEM, NETWORK SERVICE ...

Run FFS as administrator or disable its features that require elevated privileges (in global settings).

Thanks for that idea Plerry, will try it this evening.

srjones67 is right. I'd use batch scripting to achieve what you want. Example:

@ECHO OFF
"C:\Program Files\FreeFileSync\FreeFileSync.exe" "C:\path\to\first_batch"
if errorlevel 1 (
echo Errors occurred during synchronization of first batch...
pause
exit
)
"C:\Program Files\FreeFileSync ...

No dice. Running out of ideas here. I guess we have to wait until Zenju implemented the retry function. :-/

Hm. After a few days without the error (FFS cannot find the target folders on my NAS when scheduled job is executed), this evening the error returned. Decided to have a look at /var/log/messages on my NAS and indeed no wake up event logged around 17:00 (when my scheduled FFS job is executed). But ...

FFS saves a logfile by default. It's located here: %AppData%\Roaming\FreeFileSync\LastSyncs.log. If you want session based log files, just save the sync job as a batch file and execute. This is also described in the Help: FreeFileSync > Schedule a batch job.

Currently I've implemented the following workaround: I've created a batch script that will access the SMB share on my NAS, causing the drives to wake from hibernation if they are hibernating. Then wait for 20 seconds (abusing the ping command for this) before executing the FFS batch.

Batch file ...

Agreed. Perhaps let it default to 10 seconds which covers the majority of scenarios and create a customizable timeout for users who need it?

Sounds logical. I do have a multi-disk NAS by the way (Synology DS213j). In other words: what we want/need is a FFS option to customize the timeout to cope with NAS disks waking from hibernation.

I can think of several workarounds (disable hibernation, create a script that accesses the NAS just ...

I'm having the same or similar issue: when FFS batch is started via the Windows task scheduler to perform daily backup to NAS it regularly but not always fails to find the target folders on the NAS. Manual execution of the same batch after this failed scheduled attempt always works.

My NAS isn't ...