Hi!
FFS is a great tool!
I have run into a couple situations though where stale lock files (sync.ffs_lock) cause subsequent runs to get stuck - this seemingly happens at random. There are two FFS instances configured on the system, each syncing a different folder (ie d:\datastore\folder1 and d:\datastore\folder2) to a second server, and starting at different times - they should not normally be running at the same time.
I'm not sure why the lock files remain after some runs. I am running FFS out of Task Scheduler, with settings "If the task is already running, then the following rule applies: Do not start a new instance", and "Stop the task if it runs longer than 1 day" (FFS was stuck, from what I could tell, for over a week).
Worse, I get no indication that this is happening unless I manually check.
My questions:
- Under what circumstance can a lock file be left after the process ends or is terminated, or what can I check to see what the cause is?
- Is there a way to have FFS notify me if this situation continues for a long period of time? (I have email notifications enabled, but no notifications are sent and no log files are even created)
- If there isn't currently a way for FFS to send a notification in this situation, can it be added?
Lastly, email notification feature request: add an email notification option to notify on "warnings, errors, or number of files synced is greater than zero"
Thanks!
Stuck lock files, and a couple easy(?) feature requests
- Posts: 14
- Joined: 17 Aug 2020
- Posts: 4055
- Joined: 11 Jun 2019
Lock files will only get stuck if the FFS sync either never ends at all, or if it completely crashes out. A sync finishing successfully will delete the lock files. Something seems to be locking up, never starting, or killing the sync before completion. What user are you running the scheduled task under?
- Posts: 14
- Joined: 17 Aug 2020
It's currently running as administrator.
It is repeatable, and happening again. To try to clear it, we kill all running FreeFileSync processes, remove the lock file, and manually start a sync - the lock file is recreated and it hangs.
The manual sync window says "Waiting while directory is in use: <path> User name: administrator"
It is repeatable, and happening again. To try to clear it, we kill all running FreeFileSync processes, remove the lock file, and manually start a sync - the lock file is recreated and it hangs.
The manual sync window says "Waiting while directory is in use: <path> User name: administrator"
- Posts: 4055
- Joined: 11 Jun 2019
What if you run the task as current user?
- Posts: 14
- Joined: 17 Aug 2020
Administrator is the current user; that's the only account used on this server
- Posts: 4055
- Joined: 11 Jun 2019
You can confirm that someone manually enabled the administrator account and is using that as the daily driver account? That's terrible if so.
Nonetheless, disable the task and run the sync manually. See if it hangs up when run manually. If so, then you found your problem. If not, that's weird. If it's getting far enough to create a lock file, the sync has started, so it likely can't find a location. Are these network locations mapped drives?
Nonetheless, disable the task and run the sync manually. See if it hangs up when run manually. If so, then you found your problem. If not, that's weird. If it's getting far enough to create a lock file, the sync has started, so it likely can't find a location. Are these network locations mapped drives?
- Posts: 2451
- Joined: 22 Aug 2012
Note that the lock-files are created at the start of a Compare, not at the start of the actual Sync.... If it's getting far enough to create a lock file, the sync has started, ...xCSxXenon, 03 Sep 2020, 19:30
- Posts: 14
- Joined: 17 Aug 2020
Update: I was focusing on the local lock file because that's what I was seeing FFS refer to (when running manually). Turns out, there was a lock file on the OTHER side of the sync as well. After I killed the background processes and removed BOTH lock files, a manual run then worked.
I'm still not sure why the stale lock files were left in the first place.
It seems that a way to detect a stale lock file would be very helpful (in Linux, lockfiles are often created containing the owning process's PID so that subsequent instances could detect whether that process had exited and thus the lock was stale).
Also, a way to log and notify that FFS gets stuck due to a lockfile would be very helpful as well.
I'm still not sure why the stale lock files were left in the first place.
It seems that a way to detect a stale lock file would be very helpful (in Linux, lockfiles are often created containing the owning process's PID so that subsequent instances could detect whether that process had exited and thus the lock was stale).
Also, a way to log and notify that FFS gets stuck due to a lockfile would be very helpful as well.
- Posts: 4055
- Joined: 11 Jun 2019
^ Very true, typically a sync will go through if a compare goes through, unless a location drops outs and FFS doesn't stop for some reason
- Posts: 3
- Joined: 23 Jan 2019
So how do I remove the "stale" lock files on either/both ends?
(and how do I get a screen shot of the error message into this post. It is not here because I gave up, not worth the hassle.)
(and how do I get a screen shot of the error message into this post. It is not here because I gave up, not worth the hassle.)
- Posts: 4055
- Joined: 11 Jun 2019
Delete them
- Posts: 3
- Joined: 23 Jan 2019
How? Are they just files? Where are they?
Follow up - booted both my computers and the NAS. Problem solved.
Follow up - booted both my computers and the NAS. Problem solved.
- Posts: 4055
- Joined: 11 Jun 2019
They are just files, they are located in the root folder of your source and destination