Waiting while directory is locked

[gabbatron]

Hi All,

I have an FFS batch sync set up to run every 15 minutes (using Windows Task Scheduler). I noticed that for the last two weeks the sync has not run successfully once. Task Scheduler is set to kill the process after three hours as there is no way it will ever take that long in my situation.

In the log files directory, a 0KB / empty log file was being created with the time stamp but no details as to why the sync was failing.

I ran the GUI version of the sync and noticed the sync was sitting there with the message:

"Waiting while directory is locked"

I know from past experience that this is because there is a lock file that hasn't been deleted from a previous sync: "sync.ffs_lock". I simply deleted the lock file and the sync ran fine again.

Is there any way the program can have some smart logic built in to handle this situation? For example popping up a dialogue box to the user to let them know after a certain period of time or to delete the lock file itself if the lock file is X number of hours or days old.

Any assistance would be greatly appreciated.

Keep up the excellent work.

Thanks,
Adrian

[Zenju]

FFS automatically detects abandoned locks and deletes them, so there should never be a reason for manual intervention. The fact that this is not done in your case means the lock is still active and used by another FFS process instance.

[gabbatron]

Hi,

Thank you for the quick reply.

I'm not sure how that could be the case. Windows task scheduler starts the sync every 15 minutes. I've tested that the sync takes far less than this time. If the process is still running task scheduler does not start another instance of the scheduled task. After 3 hrs if the task is still running, it is terminated.

This process went on for two weeks and the computer that runs FFS is restarted every day.

Thanks,
Adrian

[Zenju]

You can check via windows task manager or process explorer if multiple FFS processes are running at the same time.

[gabbatron]

Yes I know about Task Manager. Given that the computer is restarted daily, I'm not sure how the sync never once successfully ran over a two week period when it is scheduled to run every 15 minutes.

[Zenju]

Unless you check explicitly it's not possible to exclude the possibility of multiple FFS instances running.

[solr07666]

I had a job running, that I killed in Task Manager, and could not re-run because there were lock files in the source and target folders. I logged off, and restarted FFS and could not run Compare, because it found lock files.

Once I deleted these, everything was OK. I am running v6.8 on Win2012R2

[Zenju]

FFS will clean up abandoned lock files automatically. If you don't see a counter after 30 seconds, then there is another FFS process that is keeping the lock alive.
Deleting the lock file does not solve the underlying race.

[Taiyou]

Is there a fix for this yet? I too am having failed backup jobs because of this sync.ffs_lock waiting while directory is locked problem. FFS does NOT clean up abandoned lock files automatically and the schedule is terminally broken until I go in and manually delete the lock files. I cannot be doing this very single day for 300+ workstations. Thats insane. There has to be something more reliable such as FFS reading the date/time stamp of the older lock file and ignoring it or something logical to this effect. Backing up data is priority one - not checking if a lock file is valid. I have just discovered 31 workstations that have not been backed up for 15 days!!

[Zenju]

FFS does NOT clean up abandoned lock files automatically

The lock handling including the automatic cleanup should be pretty robust. Can you try to manually start the sync an see if there is any problem with sync.ffs_lock not beeing cleaned up, and if so confirm that no other currently running sync is responsible?

[ITmgr]

I am having this same issue, but I don't see that it is associated with any lock files. We are mostly Windows users. By GPO, user's folders are redirected to a server share. At any time I want, I can open FFS, either GUI or batch, and run a sync with no issues. If I use RTS to launch the exact same batch file, whether from the GUI or using Task Scheduler, I get a grey icon in the system tray "Waiting until all directories are available..." It never clears up, and never syncs unless I do it manually. I can even open FFS and just leave the stuck process running in the system tray, and the sync will run fine but the icon will still be grey in the system tray and it will never sync. I have been using this program for many, many years and don't recall ever seeing this behavior before. I'm tempted to uninstall and start going back in time through prior releases to see when it started acting this way. I keep a pretty close eye on my backups, though, and I think this is a new behavior that has just shown up since about 8.5.

An additional clue - on the same server where I have this issue, there are two other RTS sessions that run for different folder structures, and they work fine. As a 35+ year programming veteran, my strong suspicion is the calls being used to return lock and change information do not behave the same when running as a background process as when running in foreground. BTW - this happens to be a Server 2008 R2 64-bit, so it has nothing to do with newer security models.

[nilzon]

I too can confirm this. I am running FreeFileSync v8.8 on Linux Mint 18.1. I have a sync setup between my computer and a cloud storage for backup purposes. The sync process is executed automatically (a ffs batch file started and running in background once every 15 minutes). In my source directory on my computer the file 'sync (conflicted).ffs_lock' is created every now and then, and it is not being deleted. So it ends up with several files named 'sync (conflicted 1).ffs_lock' 'sync (conflicted 2).ffs_lock' 'sync (conflicted 3').ffs_lock'.....and so on. I am sure that the ffs process is only present in one instance during the actual sync (I can see this in the Task Manager). Also there is only my one computer, and a single connection to the cloud, so it is no "multitask" issue. However the syncing is continuing and working despite the lock-files in the source directory, but several more are added as time goes by. The only way to get rid of the 'sync (conflicted).ffs_lock'-files is to delete them manually.

I really hope this could be fixed, Thanks.

[Zenju]

'sync (conflicted 1).ffs_lock' 'sync (conflicted 2).ffs_lock' 'sync (conflicted 3').ffs_lock'

The cloud storage tries to be clever and invents a completely new name "(conflicted 1')" but this hides the actual error, which is "file already existing" and breaks atomic lock file creation.
This behavior will probably create other issues during sync, too, when items are already existing and should be reported as a bug.

Anyway, dir locking can be disabled in such a case:
https://freefilesync.org/manual.php?topic=expert-settings

[Taiyou]

Hi ~

I think I found a solution. In the FreeFileSync folder, there is an xml settings file with:

<LockDirectoriesDuringSync Enabled="true"/>

Change "true" to "false". It will ignore the lock files.

[Bob_Hatcher]

I can confirm that Taiyou's solution works for me. The file is globalsettings.xml and was in the
C:\Users\Bob Hatcher\AppData\Roaming\FreeFileSync directory. Changing it to "false" works now. In the link that Zenju provides it warns that this locking is to prevent people on networks from syncing at the same time so if that's your case, proceed wisely.

[spitfire_ch]

Sorry for the late reply. I am observing the same problem. Interestingly, the FFS task does never end when being executed by the scheduler, even though the logfile reports success. The scheduler still reports the task as running, and the task still shows up in the task manager.
What could be the reason for this? Is this a problem of the scheduler?
Btw, I am executing the task as a different user (admin) than the one I am logged on. Could this be part of the problem? Thanks for any suggestions.

[GWL]

About two weeks ago I got the message "waiting while directory is locked: Y:\sync.ffs_lock". This message never goes away and nothing gets updated. I have looked every where and can not find a solution to my problem.

I am synchronizing two drives (Drive Z: and Drive Y:). Drive Z: is a local drive and drive Y: in a local network drive. I have upgraded to the latest version of FreeFileSync. Uninstalled and re-installed the program. I have looked for the file "Y:\sync.ffs_lock", and do not see such a file anywhere. I have also looked for the file Globalsettings.xml. I cannot find this file either.

I am running this program on a Win 7 machine.

Any help would be greatly appreciated.
GW

[Zenju]

About two weeks ago I got the message "waiting while directory is locked: Y:\sync.ffs_lock". This message never goes away

Either there is another FreeFileSync instance sync'ing this folder or the network share returns wrong status values indicating a file is existing while it is not. Tool to analyze such cases:
https://freefilesync.org/faq.php#trace

[courtemanche.martin]

I ran into the same issue and figured out that FFS was stopping on a file error (cannot copy file... or something).
I simply opened FFS task configuration and checked 'Ignore Errors'.
There was several FFS instances recorded in Windows Task Manager.